db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piet Blok" <pbh...@wanadoo.nl>
Subject Re: DRDA_InvalidReplyTooShort.S:Invalid reply from network server: Insufficient data.
Date Sun, 02 Apr 2006 16:49:51 GMT
Strange, it seems not to be the Derby network server that is having 
problems, only the client.

1) From an application (JVM 1) if NetworkServerControl.ping() throws an 
Exception, I start a second JVM that is to contain the network server: as 

    private void startNetwork() throws Exception {
        synchronized (sync) {
            if (processWaiter == null) {
                processWaiter = new ProcessWaiter(Runtime.getRuntime().exec(
                        new String[] { "java", 
"org.pbjar.derby.AtomicDerby" }));

2) ProcessWaiter is a class that encapsulates the Process and a Thread that 
starts reading "out" from the Process. If the first line it receives equals 
"OK", then the network server is up and running. When the first line is 
read, it shows a gui that displays all output on "out" and "err". All output 
that I myself send to "out" and "err" from the second JVM appear on this 

3) The started process "AtomicDerby" starts the Network Server as follows:

serverControl = new NetworkServerControl();
serverControl.start(new PrintWriter(pipedWriter));

The pipedWriter is connected to a pipedReader which is wrapped in a 

4) After the first line is read from this reader, I must hope that it is the 
"Server is ready to accept connections on port 1527." message. Because I 
don't want to rely on just a constant string, I format an expected value 
from ResourceBundle.getBundle("org/apache/derby/loc/drda/messages") as 
        Properties props = serverControl.getCurrentProperties();
        return MessageFormat.format(bundle.getString("DRDA_Ready.I"),
                new Object[] { 
props.getProperty("derby.drda.portNumber") });

5) Of course this may fail, because I am not yet sure that the server is up 
and running. But if it fails, I know that it is not up and have to take 
other measures. If it does not fail I can compare the received message with 
the ready line. If these are equal, I am sure that it is the server that I 
started that is in control now. In that case I send an "OK" message to 
standard out, else an "ERROR" message.

6) The message is received in the first JVM that initiated it all. On 
receiving the OK message, it invokes the getCurrentProperties method on 
NetworkServerControl, in order to format an adequate database url, with the 
correct hostname and portnumber. This is the spot where sometimes
I get a failure. Nothing suspicious to be seen on out, err, consoleWriter or 
derby.log in the network server.

It is very hard to reproduce the problem. Sometimes I get them in a row, 
sometimes everything runs smoothly, irrespective of the number of threads 
that are in use.

Anyone an idea?

Kind regards,

Piet Blok

----- Original Message ----- 
From: "Piet Blok" <pbhome@wanadoo.nl>
To: "Derby Discussion" <derby-user@db.apache.org>
Sent: Sunday, April 02, 2006 11:23 AM
Subject: Re: DRDA_InvalidReplyTooShort.S:Invalid reply from network server: 
Insufficient data.

> 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" <bpendleton@amberpoint.com>
> To: "Derby Discussion" <derby-user@db.apache.org>
> 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

View raw message