[
https://issues.apache.org/jira/browse/DERBY-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724877#action_12724877
]
Kathey Marsden edited comment on DERBY-4264 at 6/27/09 12:41 PM:
-----------------------------------------------------------------
Thank you Knut for looking at htis.
Attached is an updated diff with the ReflectMethod.toString() and the
backpointer to the RGC for ReflectMethod.
I did find that the query in question (and it seems all queries) use DirectCall
when passing through the GenericQualifier code and not ReflectMethod. I could
only seem to go through the ReflectMethod code with a CALL statement
(CallableStatementNode) which is not relevant to this issue, but it is good to
be prepared for any eventuality since I am so clueless as to the root cause.
For DirectCall I am not sure how to handle the back pointers because DirectCall
is only used in the static array directs in ReflectGeneratedClass and then
these ten DirectCalls are reused for all classes. At the point that we get
back the wrong type I don't think I can back track and find out what class was
associated when the reference was made. Do you know the best way to do this? I
guess ReflectGeneratedClass.getMethod() could take the activation and then
new up a DirectCall and pass it along instead of using the static array. Then
in DirectCall.invoke we can check that it matches the reference passed to
invoke. Would that be practical?
I don't want to change things so much that we no longer expose the bug.
was (Author: kmarsden):
Thank you Knut for looking at htis.
Attached is an updated diff with the ReflectMethod.toString() and the
backpointer to the RGC for ReflectMethod.
I did find that the query in question (and it seems all queries) use DirectCall
when passing through the GenericQualifier code and not ReflectMethod. I could
only seem to go through the ReflectMethod code with a CALL statement
(CallableStatementNode) which is not relevant to this issue, but it is good to
be prepared for any eventuality since I am so clueless as to the root cause.
For DirectCall I am not sure how to handle the back pointers because DirectCall
is only used in the static array directs in ReflectGeneratedClass and then
these ten DirectCalls are reused for all classes. At the point that we get
back the wrong type I don't think I can back track and find out what class was
associated when the reference was made. Do you know the best way to do this? I
guess ReflectGeneratedClass.getMethod() could take the activation and then
new up a DirectCall and pass it along instead of using the static array. Then
in the debug code in GenericQualifier I could check that it matched the
activation we were using at the time. Would that be too memory intensive to be
practical?
> highly intermittent java.lang.ClassCastException:
> [[Lorg.apache.derby.iapi.store.access.Qualifier; incompatible with
> org.apache.derby.iapi.types.DataValueDescriptor doing simple select
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4264
> URL: https://issues.apache.org/jira/browse/DERBY-4264
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.2.0
> Environment: Embedded Derby 10.2.2.0 - (485682)
> z/OS J2RE 1.5.0 IBM z/OS build pmz31dev-20081210 (SR9-0)
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Attachments: acf81e0010x0121xcb69x9b94x0000000eb0100.java,
> derby-4264_10.2_diag_diff.txt, derby-4264_10.2_diag_diff.txt
>
>
> I got a report from a user for a highly intermittent ClassCastException doing
> a select. Below is the stack trace:
> java.lang.ClassCastException:
> [[Lorg.apache.derby.iapi.store.access.Qualifier; incompatible
> with org.apache.derby.iapi.types.DataValueDescriptor
> at
> org.apache.derby.impl.sql.execute.GenericQualifier.getOrderable(
> Unknown Source)
> at
> org.apache.derby.impl.sql.execute.NoPutResultSetImpl.clearOrdera
> bleCache(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openSca
> nController(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Un
> known Source)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCor
> e(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(U
> nknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unkno
> wn Source)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unkno
> wn Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(Unknown
> Source)
> I don't have a reproduction yet but have some information on the schema and
> query that occasionally fails: The data here is contrived, I don't know the
> actual data in the table at the time of the failure. The column names have
> changed, but represent the same types.
> CREATE TABLE "APP"."RESOURCE"
> (
> "AUUID" CHAR(36) NOT NULL,
> "BUUID" CHAR(36) NOT NULL,
> "CUUID" CHAR(36) NOT NULL,
> "DUUID" CHAR(36) NOT NULL,
> "SECTION" CHAR(6) NOT NULL,
> "TYPE" CHAR(48) NOT NULL,
> "LASTUPDATE" TIMESTAMP NOT NULL
> );
> ALTER TABLE "APP"."RESOURCE" ADD CONSTRAINT "SQL060817095529130" PRIMARY KEY
> ("AUUID", "BUUID", "SECTION");
> -- Not sure of the actual data. This data was made up so the query would get
> a match.
> INSERT INTO RESOURCE VALUES ('3b2c2edc-1401-0000-0080-c38634aef3ba',
> '3b2c2edc-1401-0000-0080-c38634aef3bb',
> '2be1347d-2001-0000-0080-8cd524f0d034',
> '2be1347d-2001-0000-0080-8cd524f0d033', 'GENRAL', 'NodeType',
> CURRENT_TIMESTAMP);
> SELECT * FROM RESOURCE WHERE
> SECTION='GENRAL' AND
> TYPE='NodeType' AND
> DUUID='2be1347d-2001-0000-0080-8cd524f0d033' AND
> BUUID='3b2c2edc-1401-0000-0080-c38634aef3bb';
> This has happened to just one user on z/OS with J2RE 1.5.0 IBM z/OS build
> pmz31dev-20081210 (SR9-0). Other users running the same application on the
> same versions have not seen this issue. This particular user has disabled
> the functionality causing the problem for now, so I am hoping we can glean
> some information from code inspection and debugging this sample query to see
> where the cast might go wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
