Trustin I appreciate you taking time to answer my emails here :-)
In analyzing the code the ex developer wrote we have the following
segments of importance...
Ill try and add in order of appearance:
1. this is within an init method
// Create the thread pool
IoThreadPoolFilter threadPool = new IoThreadPoolFilter();
threadPool.start();
addFilter("threadPoolFilter", threadPool);
2. Then there is a JSVC (java daemon) wrapper library he has used so
to start the xmlserver he has
public Integer start(String[] string) {
if(minaXMLServerThread == null){
log.info("Mina XML Server starting..");
minaXMLServerThread = new Thread(this);
minaXMLServerThread.start();
}else{
log.info("Mina XML Server already running");
}
return null;
}
3. Most of the other stuff uses the
java.util.concurrent.CountDownLatch; class for example one of the
methods has....
private XMLResponse doSomethingSynchronously(XMLRequest request,
AbstractXMLServer server) throws XMLServerException {
XMLResponse xmlresponse = null;
// Although we send the command asynchronously to avoid blocking up
// the server, we still send the response to the client synchronously
CountDownLatch latch = new CountDownLatch(1);
DoSomethingResponseListener handler = new
DoSomethingResponseListener(latch);
// wait here unti we have got the response
try {
latch.await();
} catch (InterruptedException ex) {
log.info("Error while waiting for response from
doSomething command", ex);
// TODO: return an error response here?
}
return xmlresponse;
}
I have been speaking with one of the C++ developers and he explained
to me that all the code is doing (as he understand it) using this
Latch is waiting for the thread to go off do its thing then when its
finished it returns usually with a .join()
The code itself is a tad complex when you throw Spring into the mix
:-( and your dealing with late binding objects.
Oh the joys of being left with a project like this :-(
There was a latch used also when starting the server however the c++
developer (not knowing much java) said that looking at this new Mina
api you dont need it anymore he said that it looks like the ex
developer has added it to make up for possibly some short comings of
mina??? so I took it out and it seems to be running ok (bar a few
slight things i need to tweak) when i say running ok its running the
commands ok. I guess i just need to test with multiple clients here to
make sure.
On 1/16/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
On 1/15/07, peter ellis <[EMAIL PROTECTED]> wrote:
>
> You will have to forgive me as im only a junior java developer but do
> i need to have this code declared in the xml (mina) server we are
> developing. Obviously the mina server is going to be dealing with
> multiple connections here from various clients therefore, if i declare
> the code you specified, do i need to worry about concurrent
> connections or any notions of thread reuse/pooling.
Did the ex-developer set any thread pool settings, such as the maximum
number of threads? If not, you could just call the default constructor of
ExecutorFilter(). Otherwise, You could pass an Executor implementation by
calling some static methods in java.util.concurrent.Executors (or its
counterpart in backport-util-concurrent).
I believe the ex developer used the netbeans (threading) profiler
> (which is what im developing in) to analyze how many threads were
> being created ....would i be wise to do the same anyway following the
> code you showed me?
Yes, I think so. :) If you just want to find out how many threads are
running in a VM, then full thread dump might suffice, which is printed out
to syserr when you send '-3' signal to the VM process (i.e. kill -3 <PID>)
or press CTRL+BREAK in your windows console.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
--
Peter Ellis
Java Developer
