Bug 144819 - [test] IllegalStateException: This connection is not added to the ConnectionManager.
[test] IllegalStateException: This connection is not added to the ConnectionM...
Status: VERIFIED FIXED
Product: db
Classification: Unclassified
Component: Code
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Andrei Badea
issues@db
http://statistics.netbeans.org/except...
EXCEPTIONS_REPORT
:
: 144211 145090 145942 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-22 09:07 UTC by Jan Horvath
Modified: 2009-11-02 04:35 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
stacktrace (1.11 KB, text/plain)
2008-08-22 09:07 UTC, Jan Horvath
Details
stacktrace (1.19 KB, text/plain)
2008-08-25 07:13 UTC, gwimag
Details
stacktrace (1.19 KB, text/plain)
2008-09-03 22:40 UTC, ranbato
Details
stacktrace (1.19 KB, text/plain)
2008-09-04 17:30 UTC, gholmer
Details
stacktrace (88 bytes, text/plain)
2008-09-16 15:25 UTC, Lukas Jungmann
Details
Proposed fix (14.96 KB, text/plain)
2008-09-18 16:34 UTC, Andrei Badea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Horvath 2008-08-22 09:07:35 UTC
Build: NetBeans IDE Dev (Build 080818)
VM: Java HotSpot(TM) Client VM, 1.5.0_13-119, Java(TM) 2 Runtime Environment, Standard Edition, 1.5.0_13-b05-237
OS: Mac OS X, 10.5.4, i386

User Comments: 
just executed View Data... on a table in mysql database.

Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:338)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
Comment 1 Jan Horvath 2008-08-22 09:07:56 UTC
Created attachment 68086 [details]
stacktrace
Comment 2 Jan Horvath 2008-08-22 09:42:03 UTC
Interesting is that db explorer works well with the same connection. Please see more user comments here http://statistics.netbeans.org/analytics/detail.do?
id=86178
Comment 3 gwimag 2008-08-25 07:13:16 UTC
Build: NetBeans IDE Dev (Build 200808230201)
VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06
OS: Windows XP, 5.1, x86

User Comments: 


Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:338)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
Comment 4 gwimag 2008-08-25 07:13:25 UTC
Created attachment 68221 [details]
stacktrace
Comment 5 David Vancouvering 2008-08-25 19:23:23 UTC
Can you repeat this consistently or only randomly?
Comment 6 Jan Horvath 2008-08-26 01:30:11 UTC
so, after I updated a build, the problem disappeared. I will reopen the issue if I find reproducible case
Comment 7 davideconsonni 2008-09-02 09:33:50 UTC
today build and i get this exception:

SEVERE [org.openide.util.RequestProcessor]
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:353)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
[catch] at java.awt.EventDispatchThread.run(Unknown Source)
Comment 8 David Vancouvering 2008-09-02 16:43:30 UTC
This is mine, I've been encountering this in the unit tests as well.  Andrei backed out a change I made to fix this
because of a P1 regression it caused so not surprisingly this is back.
Comment 9 David Vancouvering 2008-09-02 18:45:06 UTC
Can you please tell me: does this happen after you change a property on the connection like the user name or schema?
Comment 10 ranbato 2008-09-03 22:40:53 UTC
Build: NetBeans IDE Dev (Build 200809020201)
VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06
OS: Windows XP, 5.1, x86

User Comments: 
Connected to a database and opened a command window.
This occurred when I tried to execute the SQL

Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:353)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
Comment 11 ranbato 2008-09-03 22:40:57 UTC
Created attachment 68987 [details]
stacktrace
Comment 12 gholmer 2008-09-04 17:30:02 UTC
Build: NetBeans IDE Dev (Build 200809020201)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-rc-b28
OS: Linux, 2.6.24-19-generic, i386

User Comments: 
1) in Services tab, Databases node:
2) use existing database connection in Services, open SQL Command window
3) close command window, select "Disconnect"
4) change properties of database connection (e.g. database name)
5) connect
6) open command window and enter an SQL command


Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:353)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
Comment 13 gholmer 2008-09-04 17:30:06 UTC
Created attachment 69084 [details]
stacktrace
Comment 14 David Vancouvering 2008-09-09 01:28:13 UTC
Reproduced.  The problem is that when you change the URL, driver, user name, or schema, of the connection, it's actually
no longer the "same" connection - it points to a different resource (or the same resource with potentially different
rights if you change the user name, which is logically a different resource).

What should happen is that in the SQL editor the selected connection should become empty, because the connection that
was previously selected no longer exists.

I'll see how to do that.
Comment 15 David Vancouvering 2008-09-09 01:33:07 UTC
*** Issue 145942 has been marked as a duplicate of this issue. ***
Comment 16 David Vancouvering 2008-09-09 01:34:04 UTC
Icky - if you change the URL back to the original, the drop-down in the SQL editor doesn't pick that up - your only
choice is the old (now broken) connection.

Even worse - if you *close* the SQL editor and open a new editor window, it *still* points to the old (non-existent)
connection, and you get the error shown on this bug if you try to do execute (or do code-completion) with it.

Gads. 
Comment 17 David Vancouvering 2008-09-12 00:00:51 UTC
It looks like the ConnectionListener for the combo box model is not getting fired.  Listeners are supposed to be
notified by ConnectionList whenever a connection has changed in some way.  Need to understand why a property change is
not causing the connection listener to be notified.
Comment 18 Lukas Jungmann 2008-09-16 15:25:10 UTC
Build: NetBeans IDE Dev (Build 20080916041613)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-b30
OS: Linux, 2.6.24-19-generic, i386

User Comments: 


Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
Comment 19 Lukas Jungmann 2008-09-16 15:25:18 UTC
Created attachment 69954 [details]
stacktrace
Comment 20 Lukas Jungmann 2008-09-16 15:36:04 UTC
just tried (looks like my comments were striped somewhere):

-start GlassFish
-create new JavaDB connection, ie "xxx"
-connect to it
-invoke Execute command on the newly added connection node
-copy & paste some sql script into the editor (or just type something yourself)
-run it

 => ISE - same stacktrace as in this report

I think this is really basic scenario which simply must work => P1 - I do not consider IDE restart as a user acceptable
workaround for this
Comment 21 David Vancouvering 2008-09-17 17:36:14 UTC
*** Issue 144211 has been marked as a duplicate of this issue. ***
Comment 22 Rob Englander 2008-09-17 19:04:05 UTC
The approach I'm leaning toward is to actually create a new connection when the user changes database, user (properties
that would render the current connection invalid), and delete the old one.  This seems like the cleanest approach so
that components that recognize added and deleted connections will respond correctly.

Anyone have any thoughts, objects, etc?
Comment 23 Andrei Badea 2008-09-17 22:48:44 UTC
I don't yet understand what exactly causes this issue, but at first sight removing the connection and creating another
one doesn't seem the right approach. This has worked since 2005, what caused it to stop working? I think we should know
that first before deciding how to fix it.

Quoting from desc15:

> What should happen is that in the SQL editor the selected connection should 
> become empty, because the connection that was previously selected no longer exists.

Why? Say I have connection jdbc:mysql://localhost/foo in DB Explorer and also selected in an SQL editor. If the user
modifies the connection URL to jdbc:mysql://localhost/bar, then the "bar" connection should be selected in the SQL
editor. The user is not creating a new connection, just modifying an existing one. If the user is modifying foo to bar,
any place where foo was used should now use bar. Only had the user deleted foo and created bar should the SQL editor
have no selected connection.
Comment 24 Rob Englander 2008-09-17 22:58:12 UTC
Although I'm still digging into the root cause, I'm not sure I agree that changing foo to bar should simply propagate
itself everywhere.  If the SQL editor is using a connection to database XXX and the user changes the connection
properties to now point to database YYY, nothing in the SQL editor from before that change makes sense anymore.

There's also another issue that I don't think has been described. Currently the user has the ability to change the
properties of one connection so that it essentially matches another existing connection.  This needs to be caught
as well.  So there's more than one issue in this one.

First step is to isolate the cause.  I'll post another comment when I have more info.
Comment 25 Lukas Jungmann 2008-09-17 23:04:52 UTC
From what I saw:

steps I mentioned in desc #21
-do work fine for MySQL db
-do not work for Java DB

not sure if that helps/is important...
Comment 26 David Vancouvering 2008-09-17 23:16:26 UTC
andrei: do you ever sleep? :)

I agree it would be good to understand why it used to work and why it doesn't.

Perhaps we can go back to say a week before the first detection of this bug in the wild occurred, and see what changed.
 I suspect it's something to do with my mucking around in there trying to get bugs fixed.

That said, I agree with Rob's observations - changing the connection properties fundamentally changes things.  It breaks
the contract with ChildFactory that equals() should be consistent across the life of an instance.  if A.equals(B) it
should always be true that A.equals(B).    We use the database connection name for equals() (and changing this is not an
easy thing - I broke things when I tried to use a UUID, remember?).  So if you change the name (by changing the URL,
user or schema) then you, from the perspective of ChildFactory, have a different beast that requires a new node.

I'm not sure what the right solution is here, but that needs to be taken into account.

One concern I have with removing the old connection and creating a new one is that if there is code using a
DatabaseConnection it's entirely possible this connection will be suddenly removed.  But I guess that can happen already
if someone manually deletes a connection from the explorer.  If you have a ConnectionListener installed you should be
able to detect this and determine if your connection is no longer valid.

Comment 27 Andrei Badea 2008-09-17 23:34:36 UTC
> nothing in the SQL editor from before that change makes sense anymore.

Not sure I understand, can you please elaborate?

What if the user simply changes the user name? How about the schema? The user is still connecting to the same database,
so would you clear the SQL editor selection in that case? Also, the user may modify the db URL to point to a similar
database on the same machine, perhaps one with the same database objects -- clearing the selection is unwanted in that
case too.

Let's look at it another way: let's say the user has three connections in the DB Explorer. He has a SQL editor, with
connection #1 selected. The user now modifies connection #1 to point to another database. You suggest that the selection
in the SQL editor connection combo box be cleared. That implies that you suppose the user will want to use one of the
other two connections in the editor -- not the one he has just modified. But that is highly unlikely. If the user
modifies a connection, it is because he still wants to work with it. Not with the other two. So we should keep the
selection in the SQL editor.

> This needs to be caught as well

Agreed, but it is a separate issue.

> and changing this is not an easy thing - I broke things when I tried to use a UUID, remember

I'm not sure why DC overrides equals(). It shouldn't be need to. There shouldn't be a lot of DC instances floating
around  and requiring that you compare them with each other. There should only be as many DC instances as there are
connections in the DB Explorer. Perhaps the problem at that time was that there were too many instances of DC and you
needed to compare them, and of course you need compare them by name. Rob's change to
DatabaseNodeInfo.getDatabaseConnection() would help fix that.

> andrei: do you ever sleep? :)

Nope, I only do guarded waiting :-)
Comment 28 David Vancouvering 2008-09-17 23:55:52 UTC
Andrei:

I can't remember all the reasons why the connection name is being used to *identify* the CNI.  Let's just say I had to
give up and back out my change.  Maybe Rob in his most excellence can unravel this bit.  I actually suspect this
dependence on name for identity could very well be at the heart of the current problem.

Regarding what connection to have selected in the editor, I agree that from the user's perspective it would be nice not
to have to re-select the connection.  But I'm willing to sacrifice that if it's the best way to solve this problem in
the time we have.
Comment 29 Andrei Badea 2008-09-18 00:02:52 UTC
Don't know either. I can look at the code tomorrow. Or, if you want, I can take this issue.

> But I'm willing to sacrifice that if it's the best way to solve this problem in
> the time we have.

If we can't invent anything better for 6.5, I would be willing too. Good that we agree on what the right behavior is, so
we can fix it properly for 7.0.
Comment 30 Rob Englander 2008-09-18 15:25:35 UTC
Behavior has changed somewhat due to changes to the trunk.  

When changing a connection property, such as the database name, the connection info does get updated.  And if you
subsequently connect, you get a connection.  But if you look at the child nodes, they are wrong.  They are the child
nodes for the previous connection.  They need to be cleared either when the connection is disconnected or when the
properties change.

I don't know if we should consider this a separate issue or just part of this one.

Comment 31 Andrei Badea 2008-09-18 15:32:10 UTC
Not sure, but I would consider it separate. Let's keep this issue for tracking the IllegalStateException. I can still
reproduce the ISE when modifying the schema of a Derby connection and then using the connection from the SQL editor.
Comment 32 Rob Englander 2008-09-18 15:42:41 UTC
Agreed.  I'll open a new issue for the child node issue.

Yes, I still see the ISE too.  That part of the behavior hasn't changed ;)
Comment 33 Andrei Badea 2008-09-18 16:04:34 UTC
The root of the problem seems to be that when a property of the connection is modified, the connection is not found in
ConnectionList.connectionCache, because the key in connectionCache is the old name.

This at least happens after I modified DatabaseNodeInfo.getDatabaseConnection() to use the existing DC instance instead
of creating a new one.
Comment 34 Rob Englander 2008-09-18 16:14:21 UTC
Yep, that's exactly what I'm looking at.
Comment 35 Andrei Badea 2008-09-18 16:23:27 UTC
I'm considering removing the cache. It is really broken. For example, if you try to remove a connection after having
modified its properties, the connection is not removed.
Comment 36 Rob Englander 2008-09-18 16:32:10 UTC
Yes, the cache uses the connection name as its key.  So changing properties means you lose the key.  I'm in the same
code, doing some of the same stuff I think.  I was experimenting with clearing a connection from the cache correctly. 
It seems we're going to step all over each other.  If you're going to get rid of the cache, I'll hold off on this until
you complete that.  I do think it would be a good idea.
Comment 37 Andrei Badea 2008-09-18 16:34:36 UTC
Created attachment 70106 [details]
Proposed fix
Comment 38 Andrei Badea 2008-09-18 16:43:22 UTC
The attached patch seems to fix the problem. It removes the connection cache, but that doesn't seem to cause any
regressions (I couldn't reproduce either of issue 137811 and issue 142036), since I am also making sure that no
additional DC instances are created. It needs more testing and polishing, but it is a start.

Not sure how to proceed from here. If you like the patch, go ahead and make any modifications you see fit and commit it.
Otherwise I can finish this.

By the way, I do realize I'm stepping on your toes. Sorry for that! Initially I only wanted to find the cause of the
issue, but in order to be sure I needed to make changes to the code, which resulted in the patch, and I didn't want to
throw it away. In a Czech movie there's this joke where a guy gets asked how he became a pathologist. "I used to be a
surgeon, but once while performing a surgery I suddenly realized I was performing an autopsy". I was only evaluating,
but suddely I realized I was fixing :-)
Comment 39 Rob Englander 2008-09-18 16:47:03 UTC
No problem.  I'm glad you found the issue.  Go ahead and finish it.  I managed to uncover a completely different issue
(Issue 147618) in the process of my own forensics :).  So I'll finish that one up.
Comment 40 Andrei Badea 2008-09-18 17:41:14 UTC
I'll finish it tomorrow.
Comment 41 Andrei Badea 2008-09-19 13:13:08 UTC
#4c829f9abb13
Comment 42 Roman Mostyka 2008-09-19 13:18:46 UTC
Honza, please verify this issue.
Comment 43 Lukas Jungmann 2008-09-19 13:29:47 UTC
yup, seems to be fine for my scenario now... will check it in some more official build later anyway
Comment 44 Quality Engineering 2008-09-20 05:47:40 UTC
Integrated into 'main-golden', will be available in build *200809200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/4c829f9abb13
User: Andrei Badea <abadea@netbeans.org>
Log: #144819: [test] IllegalStateException: This connection is not added to the ConnectionManager.
Comment 45 Lukas Jungmann 2008-09-23 16:20:05 UTC
v.
Comment 46 John Baker 2008-09-23 17:39:58 UTC
*** Issue 145090 has been marked as a duplicate of this issue. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo