IHAC who had a problem with building his project.  NetBeans+VWP was hanging
because when the project
opened there was an attempt to connect to a remote Oracle database.

It turned out that the database was in a bad state.  After restarting the
database server,
building the project could complete successfully.

To determine that Oracle was the culprit, I had to ask the Customer to generate
thread dumps since
no errors were sent to messages.log.

This might be something VWP needs to fix by timing out and throwing connection
refused
exceptions , but then again, this issue might also occur with NetBeans client
applications.

It seems that NetBeans could use a facility for dumping core when the IDE is
hanging. I suppose the IDE could be started from the commandline and user could
do Ctrl-Break from the terminal.
An alternative could be some console in a separate window/thread from the IDE to
show logs status. 

Here's some replies to the message.  For visualweb db modules we may consider
Tim's suggestion, below.


Wade Chandler wrote:
> Yes it seems this particular issue where VWP is doing
> something with the database needs to not lock the IDE.

<soapbox>
The Collaboration modules suffer from a similar disease.

There is a simple way never to have this class of problem:  Whenever you
are writing an API or facade to access some kind of remote resource or
do network I/O (or even substantial file I/O), the first line of code in
any method that can potentially do the long running thing should be:

if (EventQueue.isDispatchThread()) {
     throw new IllegalStateException();
}

in other words, before writing any code that does this sort of thing,
guarantee that it is *impossible* to write incorrect code innocently.
That entire class of bugs is eliminated.

It means dealing with the complexity of message- or visitor-based design
instead of the simplicity of making a synchronous call that makes a
network connection.  But pretending that network or database access is
free is simply kidding oneself anyway.

There are other benefits:
  - You control the thread your I/O happens on, and can guarantee that
no locks are held when I/O is entered (your code is less deadlock prone)
  - Stack traces are shallower (when an exception is thrown, it is less
expensive to create)
  - The application is guaranteed not to suffer responsiveness problems
due to I/O

</soapbox>

-Tim

>  It should be doing a task and updating (even if it
> must be indeterminate) the screen with a progress
> indicator of what is going on (even on project
> opening).  This should then show the user what steps
> are occurring so to best be able to identify where
> issues are.  This is a general rule not being observed
> by all modules and some things need to be re-adjusted
> because there are different things in modules not
> adhering to good practices in this regard.  Any long
> (or possibly long) running task should never simply
> block the UI waiting and not have a way out (cancel of
> some sort) and a good user update as to what is
> occurring.  In this case some JDBC drivers will wait a
> long time before coming back with a timeout or error
> out on connection attempts and some times DNS issues
> can cause name resolution to take a long time (even
> inside the same network...especially with VPNs).  So,
> this is technically an issue where we need all module
> owners to have code reviews with specific issue
> trackings in mind.
>
> Wade
>
> --- Tomasz Slota <Tomasz.Slota@...> wrote:
>
>> I am sorry for not having read your original message
>> carefully. Such  
>> a feature would be very useful, but I am not sure if
>> it is  
>> technically possible. Can we display any UI when the
>> AWT event  
>> dispatching thread is locked? Using JNI?
>>
>> -TS
>>
>>
>>
>> On Feb 15, 2007, at 8:21 PM, John Baker wrote:
>>
>>> Tomasz Slota wrote:
>>>> 1) You can use the jstack tool
>> (http://java.sun.com/j2se/1.5.0/
>>>> docs/tooldocs/share/jstack.html).
>>>>
>>>> 2) A quote from
>> http://java.sun.com/developer/technicalArticles/
>>>> Programming/Stacktrace:
>>>> On UNIX platforms you can send a signal to a
>> program by using the  
>>>> kill command. This is the quit signal, which is
>> handled by the  
>>>> JVM. For example, on Solaris you can use the
>> command kill -QUIT  
>>>> process_id, where process_id is the process
>> number of your Java  
>>>> program.
>>>>
>>>> Alternatively you can enter the key sequence
>> <ctrl>\ in the window  
>>>> where the Java program was started. Sending this
>> signal instructs  
>>>> a signal handler in the JVM, to recursively print
>> out all the  
>>>> information on the threads and monitors inside
>> the JVM.
>>>> To generate a stack trace on Windows 95, or
>> Windows NT platforms,  
>>>> enter the key sequence <ctrl><break> in the
>> window where the Java  
>>>> program is running, or click the Close button on
>> the window.
>>> Thanks for the suggestions.  Like I said, I used
>> Ctrl-Break and  
>>> generated a thread dump :-)
>>>
>>> The Customer expected an easier way to detect why
>> the IDE is  
>>> hanging since on Windows, typically, users
>>> don't start the IDE from commandline.
>>>
>>> If another console opened with NetBeans or better
>> yet, if the IDE  
>>> is unresponsive after sometime then
>>> a timeout would occur and send any errors to
>> messages.log for  
>>> diagnosis
>>>
>>> - John
>>>
>>>>
>>>> -TS
>>>>
>>>> On Feb 15, 2007, at 7:29 PM, John Baker wrote:
>>>>
>>>>> IHAC who had a problem with building his
>> project.  NetBeans+VWP  
>>>>> was hanging because when the project
>>>>> opened there was an attempt to connect to a
>> remote Oracle database.
>>>>> It turned out that the database was in a bad
>> state.  After  
>>>>> restarting the database server,
>>>>> building the project could complete
>> successfully.
>>>>> To determine that Oracle was the culprit, I had
>> to ask the  
>>>>> Customer to generate thread dumps since
>>>>> no errors were sent to messages.log.
>>>>>
>>>>> This might be something VWP needs to fix by
>> timing out and  
>>>>> throwing connection refused
>>>>> exceptions , but then again, this issue might
>> also occur with  
>>>>> NetBeans client
>>>>> applications.
>>>>>
>>>>> It seems that NetBeans could use a facility for
>> dumping core when  
>>>>> the IDE is hanging. I suppose the IDE could be
>> started from the  
>>>>> commandline and user could do Ctrl-Break from
>> the terminal.
>>>>> An alternative could be some console in a
>> separate window/thread  
>>>>> from the IDE to show logs status.
>>>>>
>>>>> Any suggestions/thoughts?
>>>>>
>>>>> Thanks
>>>>> John Baker
>>>> Tomasz Slota
>>>>
>>>>
>>>>
>>
>>
>>
>>
>