The mechanisme I described attempts to ensure that one and only one Network
Server will become active, even if, in multiple JVM's (on the same machine)
an attempt is made to start a server. The design goal is to enable any
application to request that a Network Server is available. If there was no
Network Server ready , a Server is launched in a separate JVM and the
application waits until that Server, or any other server, is ready.
(About a half year ago there was a long running thread in this forum on how
to start a server on the fly and wait for it to become ready, that intrigued
me)
Yes, all sorts of problems, like port in use, arise, but the mechanisme is
designed to detect these situations and cope with them. There will be only
one winner that will serve all others. The loosers just die.
The problem I described does not always occurr. In fact it only happended
once when simultaneously trying to start 30 servers. Other stress attempts,
including starting 100 servers, worked just fine.
I will try to implement a capture of the winning Server err and out streams
in order to provide the requested information when the problem occurrs
again.
Thanks very much for your answer.
Kind regards,
Piet Blok
----- Original Message -----
From: "Bryan Pendleton" <[EMAIL PROTECTED]>
To: "Derby Discussion" <[email protected]>
Sent: Saturday, April 01, 2006 9:27 PM
Subject: Re: DRDA_InvalidReplyTooShort.S:Invalid reply from network server:
Insufficient data.
When stress testing a mechanism to simultaneously start the Derby network
server from different applications at the same time, I sometimes get the
following exception:
DRDA_InvalidReplyTooShort.S:Invalid reply from network server:
Insufficient data.
Is this possibly a bug?
I'm not sure I understand the first paragraph above very well, but I can't
think of any reason you should be getting the ReplyTooShort response other
than a bug, so I would say yes, this sounds like a bug to me.
When this happens, can you look on the server side, and find your
derby.log,
and look there? Are there interesting messages there?
Also, can you capture the actual console (System.out and System.err) from
the
server side, and see if there are any interesting messages there?
I suspect that the problem is happening on the server side, and the stack
trace and error message on the client side aren't going to be all that
helpful.
If you are trying to simultaneously start multiple instances of the
network
server at the same time, aren't you going to get "port number in use"
conflicts,
and the like?
Perhaps, in addition to letting us know what you can learn from crawling
around
in your server-side logs, you could also explain a bit more about what
behavior
you are expecting to see from your server-starting mechanism that you are
testing.
thanks,
bryan
