Gilles Marceau

Ranch Hand
+ Follow
since Feb 17, 2007
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Gilles Marceau

Hello Manuel,

if i understand correctly, you have chosen to use objects serialized over socket to implement your networking code (and not the RMI framework). It means you have to code the server entirely, and also how the server will deal with the threads.
First, i found this link that should be useful on this issue :
Secondly, in my opinion, the two approaches you mentioned (one thread per client, one thread per request) have another difference than the ones
explained in the link above, this is about the client identification.
If you use the "one thread per client" approach, it's easy to identify the
client requests in the server code (and also to synchronize on a client
basis), because the thread id is the client id. On the other hand, with
the "one thread per request" approach, you don't have the client identification out-of-the-box (you need to add a token id in the request, at least inside the server process). In that case, the thread often comes
from a thread pool created at server startup.
So, knowing if you need client identification in the server code can help
you to choose between the two approaches.

Hope it helps,


PS : i used the RMI framework for my project, and in that case, there is no
choice to make, because this framework use a "one thread per request"
approach (the requests for a given client can be processed by
different threads on the server).
[ November 11, 2008: Message edited by: Gilles Marceau ]

you can use any IDE you like to code the assignment, but keep in mind
that you must code all the code yourself: it means you can't for example
use the Netbeans GUI Builder to create the Swing presentation layer.

I passed the SCJD last week, so i can give you my figures :

83 classes & interfaces, size = 284 Ko
choices.txt 48 Ko (around 18 pages)
userguide.html 20 Ko (no pictures here, around 6 pages)
Total archive size : 811 Ko

I think my projet is a bit big, but i meet the requirement concerning
the maximum size the deliverable should not exceed (1000 Ko, if i remenber

hope this helps

[ September 06, 2008: Message edited by: Gilles Marceau ]

i think you asked in the wrong forum, this one is dedicated to the SCJD certification and has nothing to do with JSP.
After about 6 months of after-work effort, this is it, it's done !
I got a 354/400 grade, with this details :

General Considerations (maximum = 100): 99
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 30
GUI (maximum = 40): 31
Locking (maximum = 80): 44
Data store (maximum = 40): 40
Network server (maximum = 40): 40

I am not surprised about the points lost in the GUI section, as my GUI was
handy, but not very polished (not mnemonic keys, for example).
I am however surprised about the locking section, i made a lot of test after a first flawn version (flawn ound thanks to some intense unit testings), and i was pretty happy of the result. I seems this part was
not so well designed.

Anyway, only the result is important.

My advices for those who are working on their assignment :
* use the java.util.Logging feature, at least on the server part,
it will help you to check the process correctness.
* use the simpliest approach (i ended up by removing some parts of the
code, because they were difficult to justify in the design choice
* write down your decision making process, as long as you think, in a
draft document (on paper, for example). This draft document will give
you the raw materials needed to write the design choice document. I
omitted to do it for some parts, and it was an extra work at the end of
the project to find again the advantages and drawback of several
possible solutions for these parts.

And finally, thank you to all the contributors of this forum for the
questions and answers available here. They were a great help and a way
to keep the motivation throughout the project.

Hello Roman,

according to this :, dynamic stub downloading can occur only if you
have installed a SecurityManager. Check your assignment, but is is likely that using a SecurityManager is forbidden. So, not using a SecurityManager should grant you that no dynamic downloading stub will occur.

But there is more on this, as from JDK 1.5, the RMI framework is able
in some case to generate the stubs at runtime, see :
at chapter "Dynamic Generation of Stub Classes (since 5.0)".
So "no dynamic downloading" is not the same that "all RMI classes pre-installed". Use rmic on the class implementing the Remote interface,
and you'll be safe.

[ September 02, 2008: Message edited by: Gilles Marceau ]

the ResourceBundle can be usefull if your application has to work in
several languages. If your assignment don't have this requirement, i think
you can do as proposed by Alex, or you can directly hardcode the text
in the code (but this is not something to do at the job) :
JOptionPane.showMessageDialog(null, "What's UP!")

The exact statement from my assignement is "Your programs must not require
use of command line arguments other than the single mode flag, which must
be supported", the single mode flag being "alone" or "server".

Using a command line property argument for logging doesn't conflict with
this requirement, because the application runs perfectly without logs
(if your logs are well written, i.e doesn't change any state anywhere in
the code).

It means the end user can use the application without knowing that this
logging feature exists.
Hi Chris,

the interrest of logging is to be able to select at runtime some
part of your software, and get information from this part at a given
level of detail. To do so, you have to :

1) use Logger static instance in each class where you want information,
giving to the Logger the name of the class.
(for example, using this syntax in a ClassName class :
private static final Logger LOGGER =

2) use logging level accurately (see the javadoc on how use the various
logging level, from finest to severe).

3) use a logging configuration file. This point answer to your question
about who control the logging. This is not intended to the end user, but
more for the developper, and you specify it as a java property on the
java command line :
To see an example of logging config file (this is in fact the default
one), see in your JRE directory the file : lib/

Using these three steps, you will be able in your development work to
select, let's say the database part only at a maximum level, putting
the rest of the application and the J2SE core classes to the info level, updating the default file with :

java.util.logging.ConsoleHandler.level = FINEST
.level = INFO
yourtoppackage.db = FINEST

About your two other questions :
* i used the loggers mainly in the db code, but also in the GUI part
to log unexpected Exception, for example.
* i used logging with only one application at a time, so it was impossible
to encounter the case you mentionned. However, i think there is no
problem if you use the FileHandler in the default lib/
configuration file (as the %u is meant to resolve conflict).

Hope this helps,

Hello Alejandro,

I think the key is the assignement sentence "A null value in criteria[n] matches any field value". In my opinion, this statement stands for the
field[n] only. Having a null value at criteria[n] doesn't mean
the result is the whole database, it does just mean that there is no
filtering process to do on the records field[n].

Hope this help

Hello Chris,

i am currently finishing the B&S assignment, so maybe i can give you
some advices on how to test the DB implementation based on my experience
(although i didn't submit my assigment yet, meaning i could be wrong in my
approach). Anyway, here is how i tested my own DB implementation :

1) first, use java.util.Logger intensively in the database implementation.
It is part of the J2SE core classes and can be disabled at runtime, so
this is in the scope of the assignement. This allow you to check
exactly what the database code has done. Then performs several simple
case ( several threads updating the same record for example, find
on all the database), and check the results.

2) use JUnit to automate the test process. Here, i would advise
to use the Callable interface to launch client threads (and not
Runnable), because it's easier this way to get the Exception occuring
in the client thread code.
Here, you can check that every client thread has finishing its job
(detecting some possible deadlock), that the database supports the
load and that concurrent accesses create not data corruption or lost.

2) use JCarder on all the test you made in 2):
This is an open source dynamic deadlock finder. According to the tests i
have made, it can find possible deadlock even if it doesn't occurs,
which makes it very powerful. You just need to run the instrumented
code on the use case involved. Note that this tool has limitations
(mainly, don't work on java.util.concurrent classes).

I hope this helps,

Ok, finally i found the answer, it was in the API.
All the process i explained is useless because UnicastRemoteObject.unexportObject has everything i need : by calling it with
the force parameter to false, the unexport process succeed only if there is no thread in process on the object to remove.
So I just need to call it until if complete successfully.
9 years ago
Well, maybe i should clarify my question to get more answers...

The issue is, in a RMI based server, how to handle waiting
thread inside the server (exposed remotly by the RMI framework)
at shutdown time.

Thanks in advance,

9 years ago
hello Ranchers,

i am trying to design a clean remote object unexport with RMI, and
i am facing the following problem : how to be sure that no RMI
thread is still working inside the remote object ?
A clean solution would be to shut down the remote object (all
calls give a RemoteException) and wait for the completion of all other
threads that could be on going. Is there a way to count the number
of RMI thread running at a given time ? I didn't find how to do so,
so i made a kind of proxy on the remote object to count the
incoming/outcoming calls. When the count is zero, the remote object
can be unexported safely (this is the rough idea).

Does any of you think of a better solution ?


9 years ago
Thank you for you reply, i will have a look.
However, i am not using an Executor directly.
Maybe some process use one behind the scene.
I also have two shutdown hocks that could be
part of the problem.

I will check !

9 years ago