Connection is closed on line editing and committing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Connection is closed on line editing and committing

Peilke, Hendrik

Hi,

 

I discovered a problem in uDig 1.3.2: It occurs when drawing lines using the standard line drawing tool and committing as soon as drawing is finished (by hitting the commit button immediately after [enter] or double clicking). If the described procedure is done multiple times, I get a connection is closed exception before the fifth iteration. Something (renderer) called a connection.close() (on the dbcp connection wrapper) on the EditManager-transaction-connection. After the connection was closed, no more lines can be drawn.

 

I am using an Oracle database connection (on a win32 system), although I don’t think, after debugging, that it has anything to do with it.

 

I cannot confirm if this error still exists in uDig 1.4.0, because I after adding an oracle spatial geometry layer, the renderer.draw() just gives me a lot of null pointer exceptions.

 

Main cause of the use of uDig, mentioned above, is to have every change safely committed to the database (not relying on the reliability of the program). Is there any other method (like turning auto commit on for the edit connection)? Can the connection somehow be recovered in that scenario, like by reinitializing the transaction? Has somebody an idea, how the problem can be fixed?

 

Regards,

Hendrik Peilke



IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter
Vorsitzender des Aufsichtsrates: Dr. Wolfgang Habel

_______________________________________________
udig-users mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/udig-users
Reply | Threaded
Open this post in threaded view
|

Re: Connection is closed on line editing and committing

Jody Garnett-2

I discovered a problem in uDig 1.3.2: It occurs when drawing lines using the standard line drawing tool and committing as soon as drawing is finished (by hitting the commit button immediately after [enter] or double clicking). If the described procedure is done multiple times, I get a connection is closed exception before the fifth iteration. Something (renderer) called a connection.close() (on the dbcp connection wrapper) on the EditManager-transaction-connection. After the connection was closed, no more lines can be drawn.

I seem to recall running into this and fixing it last year.

I am using an Oracle database connection (on a win32 system), although I don’t think, after debugging, that it has anything to do with it.

 

I cannot confirm if this error still exists in uDig 1.4.0, because I after adding an oracle spatial geometry layer, the renderer.draw() just gives me a lot of null pointer exceptions.

Would be interested to know the stack trace of that, I cannot remember the differences between 1.3.2 and 1.4.0. 

Main cause of the use of uDig, mentioned above, is to have every change safely committed to the database (not relying on the reliability of the program). Is there any other method (like turning auto commit on for the edit connection)? Can the connection somehow be recovered in that scenario, like by reinitializing the transaction? Has somebody an idea, how the problem can be fixed?

I had not considered making an "auto commit" mode, mostly as with shape files that involves writing out the entire shapefile each time.
 
However one thing you can do is go to the catalog, right click, and "reset" the database. This will recreate it with a new connection pool. 

_______________________________________________
udig-users mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/udig-users
Reply | Threaded
Open this post in threaded view
|

Re: Connection is closed on line editing and committing

Peilke, Hendrik
In reply to this post by Peilke, Hendrik
>> I discovered a problem in uDig 1.3.2: It occurs when drawing lines using the standard line drawing tool and committing as soon as drawing is finished (by hitting the commit button immediately after [enter] or double clicking). If the described procedure is done multiple times, I get a connection is closed exception before the fifth iteration. Something (renderer) called a connection.close() (on the dbcp connection wrapper) on the EditManager-transaction-connection. After the connection was closed, no more lines can be drawn.
>
> I seem to recall running into this and fixing it last year.
>
>> I am using an Oracle database connection (on a win32 system), although I don?t think, after debugging, that it has anything to do with it.
>> I cannot confirm if this error still exists in uDig 1.4.0, because I after adding an oracle spatial geometry layer, the renderer.draw() just gives me a lot of null pointer exceptions.
>
> Would be interested to know the stack trace of that, I cannot remember the differences between 1.3.2 and 1.4.0.
>

The stack trace is:

!ENTRY net.refractions.udig.project 2 0 2013-08-14 08:31:51.026
!MESSAGE class java.lang.NullPointerException occured during rendering: null
!STACK 0
net.refractions.udig.project.render.RenderException: class java.lang.NullPointerException occured during rendering: null
        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:484)
        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:315)
        at net.refractions.udig.project.internal.render.impl.RenderJob.startRendering(RenderJob.java:117)
        at net.refractions.udig.project.internal.render.impl.RenderJob.run(RenderJob.java:222)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.NullPointerException
        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.prepareDraw(BasicFeatureRenderer.java:203)
        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:352)
        ... 4 more

It would be great, if you could help on this error.

>> Main cause of the use of uDig, mentioned above, is to have every change safely committed to the database (not relying on the reliability of the program). Is there any other method (like turning auto commit on for the edit connection)? Can the connection somehow be recovered in that scenario, like by reinitializing the transaction? Has somebody an idea, how the problem can be fixed?
>
> I had not considered making an "auto commit" mode, mostly as with shape files that involves writing out the entire shapefile each time.
>
> However one thing you can do is go to the catalog, right click, and "reset" the database. This will recreate it with a new connection pool.
>

Thanks. That worked.

________________________________
IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter
Vorsitzender des Aufsichtsrates: Dr. Wolfgang Habel
_______________________________________________
udig-users mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/udig-users
Reply | Threaded
Open this post in threaded view
|

Re: Connection is closed on line editing and committing

Peilke, Hendrik
In reply to this post by Peilke, Hendrik

> Just to verify whats going on: 

> * Do you have null geometries in the database? 

 

No, there are no null geometries in the referenced tables.

 

> * Or even Geometries without an valid SRID?

 

The geometries in our database have an own SRID, which we defined ourselves.  Since this was very close to 31468, we chose that one as the CRS in uDig 1.3.2 layers and maps and everything worked out just fine.  If the problem with uDig 1.4.0 is now, that it tries to find our own SRID, is there a way to add our own SRID to uDig?

 

> - Frank

> 2013/8/19 Peilke, Hendrik <[hidden email]>

>>> I discovered a problem in uDig 1.3.2: It occurs when drawing lines using the standard line drawing tool and committing as soon as drawing is finished (by hitting the commit button immediately after [enter] or double clicking). If the described procedure is done multiple times, I get a connection is closed exception before the fifth iteration. Something (renderer) called a connection.close() (on the dbcp connection wrapper) on the EditManager-transaction-connection. After the connection was closed, no more lines can be drawn.

>> 

>> I seem to recall running into this and fixing it last year.

>> 

>>> I am using an Oracle database connection (on a win32 system), although I don?t think, after debugging, that it has anything to do with it.

>>> I cannot confirm if this error still exists in uDig 1.4.0, because I after adding an oracle spatial geometry layer, the renderer.draw() just gives me a lot of null pointer exceptions.

>> 

>> Would be interested to know the stack trace of that, I cannot remember the differences between 1.3.2 and 1.4.0.

>> 

> The stack trace is:

>

> !ENTRY net.refractions.udig.project 2 0 2013-08-14 08:31:51.026

> !MESSAGE class java.lang.NullPointerException occured during rendering: null

> !STACK 0

> net.refractions.udig.project.render.RenderException: class java.lang.NullPointerException occured during rendering: null

>        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:484)

>        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:315)

>        at net.refractions.udig.project.internal.render.impl.RenderJob.startRendering(RenderJob.java:117)

>        at net.refractions.udig.project.internal.render.impl.RenderJob.run(RenderJob.java:222)

>        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

> Caused by: java.lang.NullPointerException

>        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.prepareDraw(BasicFeatureRenderer.java:203)

>        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:352)

>        ... 4 more

> It would be great, if you could help on this error.

>>> Main cause of the use of uDig, mentioned above, is to have every change safely committed to the database (not relying on the reliability of the program). Is there any other method (like turning auto commit on for the edit connection)? Can the connection somehow be recovered in that scenario, like by reinitializing the transaction? Has somebody an idea, how the problem can be fixed?

>> 

>> I had not considered making an "auto commit" mode, mostly as with shape files that involves writing out the entire shapefile each time.

>> 

>> However one thing you can do is go to the catalog, right click, and "reset" the database. This will recreate it with a new connection pool.

>> 

> Thanks. That worked.

 



IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter
Vorsitzender des Aufsichtsrates: Dr. Wolfgang Habel

_______________________________________________
udig-users mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/udig-users
Reply | Threaded
Open this post in threaded view
|

Re: Connection is closed on line editing and committing

fgdrf



2013/8/19 Peilke, Hendrik <[hidden email]>

> Just to verify whats going on: 

> * Do you have null geometries in the database? 

 

No, there are no null geometries in the referenced tables.

Thats good! 

 

> * Or even Geometries without an valid SRID?

 

The geometries in our database have an own SRID, which we defined ourselves.  Since this was very close to 31468, we chose that one as the CRS in uDig 1.3.2 layers and maps and everything worked out just fine.  If the problem with uDig 1.4.0 is now, that it tries to find our own SRID, is there a way to add our own SRID to uDig?

 

Have a look at the following thread, how and wher to define a custom CRS : http://gis.19327.n5.nabble.com/Overriding-existing-CRS-td5506493.html

HTH,
Frank 

> - Frank

> 2013/8/19 Peilke, Hendrik <[hidden email]>

>>> I discovered a problem in uDig 1.3.2: It occurs when drawing lines using the standard line drawing tool and committing as soon as drawing is finished (by hitting the commit button immediately after [enter] or double clicking). If the described procedure is done multiple times, I get a connection is closed exception before the fifth iteration. Something (renderer) called a connection.close() (on the dbcp connection wrapper) on the EditManager-transaction-connection. After the connection was closed, no more lines can be drawn.

>> 

>> I seem to recall running into this and fixing it last year.

>> 

>>> I am using an Oracle database connection (on a win32 system), although I don?t think, after debugging, that it has anything to do with it.

>>> I cannot confirm if this error still exists in uDig 1.4.0, because I after adding an oracle spatial geometry layer, the renderer.draw() just gives me a lot of null pointer exceptions.

>> 

>> Would be interested to know the stack trace of that, I cannot remember the differences between 1.3.2 and 1.4.0.

>> 

> The stack trace is:

>

> !ENTRY net.refractions.udig.project 2 0 2013-08-14 08:31:51.026

> !MESSAGE class java.lang.NullPointerException occured during rendering: null

> !STACK 0

> net.refractions.udig.project.render.RenderException: class java.lang.NullPointerException occured during rendering: null

>        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:484)

>        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:315)

>        at net.refractions.udig.project.internal.render.impl.RenderJob.startRendering(RenderJob.java:117)

>        at net.refractions.udig.project.internal.render.impl.RenderJob.run(RenderJob.java:222)

>        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

> Caused by: java.lang.NullPointerException

>        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.prepareDraw(BasicFeatureRenderer.java:203)

>        at net.refractions.udig.render.internal.feature.basic.BasicFeatureRenderer.render(BasicFeatureRenderer.java:352)

>        ... 4 more

> It would be great, if you could help on this error.

>>> Main cause of the use of uDig, mentioned above, is to have every change safely committed to the database (not relying on the reliability of the program). Is there any other method (like turning auto commit on for the edit connection)? Can the connection somehow be recovered in that scenario, like by reinitializing the transaction? Has somebody an idea, how the problem can be fixed?

>> 

>> I had not considered making an "auto commit" mode, mostly as with shape files that involves writing out the entire shapefile each time.

>> 

>> However one thing you can do is go to the catalog, right click, and "reset" the database. This will recreate it with a new connection pool.

>> 

> Thanks. That worked.

 



IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter
Vorsitzender des Aufsichtsrates: Dr. Wolfgang Habel


_______________________________________________
udig-users mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/udig-users
Reply | Threaded
Open this post in threaded view
|

Connection is closed on line editing and committing

Peilke, Hendrik
In reply to this post by Peilke, Hendrik

Hi,

 

in August 2013 I reported an error happening to me with uDig 1.3.2 when drawing lines using the standard line drawing tool and committing as soon as drawing is finished (by hitting the commit button immediately after [enter] or double clicking). Jody Garnett remembered that error and thought it was fixed. At that time I was not able to test this behavior with uDig 1.4.0, but now I set up the metadata tables correctly and the error still exists with 1.4.0.

 

If the described procedure (draw-commit-draw-commit) is done multiple times, I get a connection is closed exception from the connection pool before the fifth iteration. Something (renderer) called a connection.close() (on the dbcp connection wrapper) on the EditManager-transaction-connection. After the connection was closed, no more lines can be drawn. The stack trace is:

 

!ENTRY net.refractions.udig.tools.edit 1 0 2014-01-31 14:53:31.610

!MESSAGE

!STACK 0

java.io.IOException

                at org.geotools.jdbc.JDBCFeatureStore.getWriterInternal(JDBCFeatureStore.java:318)

                at org.geotools.data.store.ContentFeatureStore.getWriter(ContentFeatureStore.java:150)

                at org.geotools.data.store.ContentFeatureStore.getWriter(ContentFeatureStore.java:121)

                at org.geotools.data.store.ContentFeatureStore.getWriterAppend(ContentFeatureStore.java:261)

                at org.geotools.data.store.ContentFeatureStore.addFeatures(ContentFeatureStore.java:240)

                at org.geotools.data.SimpleFeatureStoreBridge.addFeatures(SimpleFeatureStoreBridge.java:48)

                at net.refractions.udig.project.internal.impl.UDIGSimpleFeatureStore.addFeatures(UDIGSimpleFeatureStore.java:284)

                at net.refractions.udig.project.internal.commands.edit.AddFeatureCommand.run(AddFeatureCommand.java:88)

                at net.refractions.udig.tools.edit.commands.CreateAndSelectNewFeature.run(CreateAndSelectNewFeature.java:81)

                at net.refractions.udig.project.command.UndoableComposite.execute(UndoableComposite.java:82)

                at net.refractions.udig.tools.edit.BehaviourCommand.execute(BehaviourCommand.java:60)

                at net.refractions.udig.project.command.UndoableComposite.execute(UndoableComposite.java:79)

                at net.refractions.udig.project.command.CommandManager$Executor.execute(CommandManager.java:395)

                at net.refractions.udig.project.command.CommandManager$Executor.run(CommandManager.java:326)

                at net.refractions.udig.project.command.CommandManager$Executor.run(CommandManager.java:312)

                at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Caused by: java.sql.SQLException: Connection is closed.

                at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.checkOpen(PoolingDataSource.java:185)

                at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:317)

                at org.geotools.jdbc.JDBCDataStore.selectSQLPS(JDBCDataStore.java:3094)

                at org.geotools.jdbc.JDBCFeatureStore.getWriterInternal(JDBCFeatureStore.java:271)

                ... 15 more

 

I am using an Oracle database connection (on a win32 system), although I don’t think, after debugging, that it has anything to do with it.

 

It seems to me that there is a missing synchronization, because it doesn’t always happen at the same time and you need a fast commit hit after finishing the line drawing: Drawing the edited layer through a renderer (probably triggered by the commit) ends with closing the connection for drawing (this is standard), but somehow at this point it uses the editing connection (probably because the transaction is still busy and so the connection is currently registered with this layer?) for drawing request and closes it (inside dbcp), although it is still registered with the transaction in the edit manager.

 

Regards,

Hendrik Peilke



IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter
Vorsitzender des Aufsichtsrates: Dr. Wolfgang Habel

_______________________________________________
udig-users mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/udig-users