db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Using NetworkServerControl to access in-memory (only) tables of Embedded Derby
Date Thu, 18 Feb 2010 18:36:18 GMT
On 18.02.10 18:47, Pavel Bortnovskiy wrote:
> Hello, Kristian:
>
> Thanks for your response.
>
> I think I found what the problem is... When my IDE (IntelliJ IDEA) hits a
> breakpoint, it suspends all threads. I find it funny that in all these
> years of programming and using IDEA, I've never realized it.
> (possibly because I was too occupied debugging the code at the breakpoint
> and not thinking about other threads at that moment). I've searched
> through the options but couldn't find any setting
> which will prevent other threads from being suspended. Will continue
> looking.
>
> I am now curious, what IDE do you use that it worked for you? And did you
> need to enable any special settings to allow all other threads to continue
> execution?
>
>    

Hi Pavel,

Glad to hear you figured out what caused your problems.

For the record, I'm using NetBeans.
I haven't tuned any nobs, stopping the current thread only is the 
default I believe. You can stop all threads on a breakpoint if you want 
to, and you can also make a different thread the current thread, 
interrupt threads, and suspend threads.


Regards,
-- 
Kristian

>    
> Regards,
>
> Pavel.
>
>
>
>
>
>
>
> Kristian Waagan<Kristian.Waagan@Sun.COM>
> Sent by: Kristian.Waagan@Sun.COM
> 02/16/2010 03:32 AM
> Please respond to
> "Derby Discussion"<derby-user@db.apache.org>
>
>
> To
> Derby Discussion<derby-user@db.apache.org>
> cc
>
> Subject
> Re: Using NetworkServerControl to access in-memory (only) tables of
> Embedded Derby
>
>
>
>
>
>
> On 16.02.10 03:02, Pavel Bortnovskiy wrote:
>    
>> 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
>> experiencing
>> such hang-ups.
>>
>>      
> Hi Pavel,
>
> The code I'm about to post is by no means to be considered best
> practice, but I think it does what you want it to do. However, the code
> is basically yours :) (I copied it from your mail)
> When I hit the breakpoint (set on the System.out.println in the static
> main method), the ping thread continued to run, and I could also access
> and do things with the database through ij.
>
> Are you sure you're only stopping the current thread in your debugger?
> When the system appears to hang, can you obtain a stack trace (using
> jstack or similar) and check what the Derby threads are doing?
> Are you sure your stopped thread isn't holding on to some monitors /
> locks required by the other threads? (sounds unlikely, as the Derby
> threads should operate on their own, but I'm asking anyway...)
>
> See the code I tested with below (I'm using localhost as host, so you
> cannot connect to Derby remotely).
>
>
> Regards,
>    


Mime
View raw message