db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Bortnovskiy <PBortnovs...@Jefferies.com>
Subject Re: Using NetworkServerControl to access in-memory (only) tables of Embedded Derby
Date Tue, 16 Feb 2010 02:02:08 GMT
Bryan: thank you for your response.

I do see the thread you mention:

        Thread Group [derby.daemons]{10}(Daemon)
            Thread [derby.antiGC]{1}(Daemon)(WAITING)
            Thread [derby.rawStoreDaemon]{5}(Daemon)(TIMED_WAITING)
            Thread [derby.NetworkServerStarter]{5}(Daemon)(WAITING)
            Thread [NetworkServerThread_2]{5}(Daemon)(RUNNABLE)
            Thread [DRDAConnThread_3]{5}(Daemon)(WAITING)

However the behavior is still the same - if any other thread stops (for 
instance in debugger), NetworkServerControl becomes unresponsive.
For instance, if I connect to it from the "outside" with another db app 
(Aqua Data Studio, for instance), then connection to it breaks or the db 
app can't access it.
But as soon as I let the thread run in that debugger, the connection 
becomes alive and everything seems to work.

Has anyone else seen this kind of behavior?
Or perhaps, someone can share a piece of code (best practice) of how to 
instantiate and run the NetworkServerControl, so that it's not 
such hang-ups.

Much appreciated,


Bryan Pendleton <bpendleton@amberpoint.com> 
02/05/2010 12:07 PM
Please respond to
"Derby Discussion" <derby-user@db.apache.org>

Derby Discussion <derby-user@db.apache.org>

Re: Using NetworkServerControl to access in-memory (only) tables of 
Embedded Derby

> DerbyServer thread seems to still be running, yet the server is 
> unresponsive.

In addition to your own DerbyServer thread, which I don't think
actually *needs* to still be running, there should be a separate
thread which is started by the Derby network server code itself,
which has the job of accepting connections and delivering them
to other threads to be processed.

In my running network server, for example, when I look at the
threads that are active, I see:

"NetworkServerThread_2" prio=6 tid=0x03044c80 nid=0x27c runnable 
         at java.net.PlainSocketImpl.socketAccept(Native Method)
         at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
         - locked <0x22a857d8> (a java.net.SocksSocketImpl)
         at java.net.ServerSocket.implAccept(ServerSocket.java:450)
         at java.net.ServerSocket.accept(ServerSocket.java:421)
         at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source)
         at java.security.AccessController.doPrivileged(Native Method)
         at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)

Do you see a thread like that?

When your server becomes stuck/wedged/unresponsive, why don't you try 
  - collect a thread dump of the entire JVM
  - look through the threads for any which mention "org.apache.derby" in 
their stacks
  - edit out all the other threads from your thread dump

Then post a message with a cut-and-paste of just the derby-related threads
in your wedged server, and maybe it will be more clear to somebody else
what the problem is.



Jefferies archives and monitors outgoing and incoming e-mail. The contents of this email,
including any attachments, are confidential to the ordinary user of the email address to which
it was addressed. If you are not the addressee of this email you may not copy, forward, disclose
or otherwise use it or any part of it in any form whatsoever. This email may be produced at
the request of regulators or in connection with civil litigation. Jefferies accepts no liability
for any errors or omissions arising as a result of transmission. Use by other than intended
recipients is prohibited.  In the United Kingdom, Jefferies operates as Jefferies International
Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames
Street, London EC4V 3BJ.  Jefferies International Limited is authorised and regulated by the
Financial Services Authority.
View raw message