TypeException:user.main[2]:'A0' may not be used before being initialized
Dear MonetDB users,
Have you experienced anything like this before?
TypeException:user.main[2]:'A0' may not be used before being initialized. Stacktrace follows: java.sql.SQLException: TypeException:user.main[2]:'A0' may not be used before being initialized at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.executeQuery(MonetConnection.java:2535) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.processQuery(MonetConnection.java:2284) at nl.cwi.monetdb.jdbc.MonetStatement.internalExecute(MonetStatement.java:508) at nl.cwi.monetdb.jdbc.MonetStatement.execute(MonetStatement.java:349) at nl.cwi.monetdb.jdbc.MonetPreparedStatement.<init>(MonetPreparedStatement.java:118) at nl.cwi.monetdb.jdbc.MonetConnection.prepareStatement(MonetConnection.java:901) at nl.cwi.monetdb.jdbc.MonetConnection.prepareStatement(MonetConnection.java:825) at org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:281) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:313) (...)
What do you recommend? Should I open a bug report?
Ruben Silva
Hi Ruben
This looks like an error in the code produced for a particular query. Can you identify that query and the underlying scheme?
thanks, Martin
On 11/7/13 5:28 PM, Ruben Silva wrote:
Dear MonetDB users,
Have you experienced anything like this before?
TypeException:user.main[2]:'A0' may not be used before being initialized. Stacktrace follows: java.sql.SQLException: TypeException:user.main[2]:'A0' may not be used before being initialized at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.executeQuery(MonetConnection.java:2535) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.processQuery(MonetConnection.java:2284) at nl.cwi.monetdb.jdbc.MonetStatement.internalExecute(MonetStatement.java:508) at nl.cwi.monetdb.jdbc.MonetStatement.execute(MonetStatement.java:349) at nl.cwi.monetdb.jdbc.MonetPreparedStatement.<init>(MonetPreparedStatement.java:118) at nl.cwi.monetdb.jdbc.MonetConnection.prepareStatement(MonetConnection.java:901) at nl.cwi.monetdb.jdbc.MonetConnection.prepareStatement(MonetConnection.java:825) at org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:281) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:313) (...)
What do you recommend? Should I open a bug report?
Ruben Silva
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
Hello Martin,
Looks like the problem it's related with inserts in a specific TABLE. The insert by itself does not have notthing special about it:
INSERT INTO "CUBE_f21317a4f3e34fd895de2fa6c1d07310_FACT"("ID", "CUBE_LOAD_ID", "INSERT_DATE", "UPDATE_DATE", "ATTR_3d82e2b7ea1b44c1b43715811e10164a", "ATTR_9eb89b711aaf4c62bc1a4615e36d51b3", "ATTR_ba67d32fde6e47058cd0b704fca4c4dc", "ATTR_8e8f1274dbf94a53ba82506ef2ce27bb", "ATTR_73ffb9de993d4a4889ce0400d39a5f8a", "ATTR_e7e7e6975e7d4e54b74f49da611aad93", "ATTR_086c1b52010d4871abce83bc904ef173", "ATTR_ea58cc1de0ad4314a31f2c2af6203de4", "ATTR_6c6d1a98a9cd42aa872d0be7de9807eb", "ATTR_162e3b62abd446dd9f21251bb67ca8e1", "ATTR_e912e91c81a144398e071e51576171a4", "ATTR_97b6e5c8fb3b43e1ac9beadeb6b1fbee", "ATTR_cbb2c319a54d4bd4a2ba625fb12b7fb3") values(:primaryKey ,:cubeLoadId ,:insertDate ,:updateDate ,:3d82e2b7ea1b44c1b43715811e10164a ,:9eb89b711aaf4c62bc1a4615e36d51b3 ,:ba67d32fde6e47058cd0b704fca4c4dc ,:8e8f1274dbf94a53ba82506ef2ce27bb ,:73ffb9de993d4a4889ce0400d39a5f8a ,:e7e7e6975e7d4e54b74f49da611aad93 ,:086c1b52010d4871abce83bc904ef173 ,:ea58cc1de0ad4314a31f2c2af6203de4 ,:6c6d1a98a9cd42aa872d0be7de9807eb ,:162e3b62abd446dd9f21251bb67ca8e1 ,:e912e91c81a144398e071e51576171a4 ,:97b6e5c8fb3b43e1ac9beadeb6b1fbee ,:cbb2c319a54d4bd4a2ba625fb12b7fb3)
Restarting MonetDB temporarly solves the problem. I can collect some additional info, just point me where to.
Regards,
RS
Hi
The query in isolation does not pose any problems to the server, neither when i first turn the INSERT into a prepare statement and then EXEC it.
The symptoms hint at either re-establishment of a connection that leads to a cleared query cache, or passing a wrong alias in the front-end code to executed a prepared query.
The TypeException seems to indicate that you attempt to execute an wrongly formatted query.
I would trace the actual interaction using the JDB trace options and make sure that all information is handled by the same connection.
regards, Martin
On 11/7/13 6:38 PM, Ruben Silva wrote:
Hello Martin,
Looks like the problem it's related with inserts in a specific TABLE. The insert by itself does not have notthing special about it:
INSERT INTO "CUBE_f21317a4f3e34fd895de2fa6c1d07310_FACT"("ID", "CUBE_LOAD_ID", "INSERT_DATE", "UPDATE_DATE", "ATTR_3d82e2b7ea1b44c1b43715811e10164a", "ATTR_9eb89b711aaf4c62bc1a4615e36d51b3", "ATTR_ba67d32fde6e47058cd0b704fca4c4dc", "ATTR_8e8f1274dbf94a53ba82506ef2ce27bb", "ATTR_73ffb9de993d4a4889ce0400d39a5f8a", "ATTR_e7e7e6975e7d4e54b74f49da611aad93", "ATTR_086c1b52010d4871abce83bc904ef173", "ATTR_ea58cc1de0ad4314a31f2c2af6203de4", "ATTR_6c6d1a98a9cd42aa872d0be7de9807eb", "ATTR_162e3b62abd446dd9f21251bb67ca8e1", "ATTR_e912e91c81a144398e071e51576171a4", "ATTR_97b6e5c8fb3b43e1ac9beadeb6b1fbee", "ATTR_cbb2c319a54d4bd4a2ba625fb12b7fb3") values(:primaryKey ,:cubeLoadId ,:insertDate ,:updateDate ,:3d82e2b7ea1b44c1b43715811e10164a ,:9eb89b711aaf4c62bc1a4615e36d51b3 ,:ba67d32fde6e47058cd0b704fca4c4dc ,:8e8f1274dbf94a53ba82506ef2ce27bb ,:73ffb9de993d4a4889ce0400d39a5f8a ,:e7e7e6975e7d4e54b74f49da611aad93 ,:086c1b52010d4871abce83bc904ef173 ,:ea58cc1de0ad4314a31f2c2af6203de4 ,:6c6d1a98a9cd42aa872d0be7de9807eb ,:162e3b62abd446dd9f21251bb67ca8e1 ,:e912e91c81a144398e071e51576171a4 ,:97b6e5c8fb3b43e1ac9beadeb6b1fbee ,:cbb2c319a54d4bd4a2ba625fb12b7fb3)
Restarting MonetDB temporarly solves the problem. I can collect some additional info, just point me where to.
Regards,
RS
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
participants (2)
-
Martin Kersten -
Ruben Silva