db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4264) highly intermittent java.lang.ClassCastException: [[Lorg.apache.derby.iapi.store.access.Qualifier; incompatible with org.apache.derby.iapi.types.DataValueDescriptor doing simple select
Date Sat, 27 Jun 2009 18:54:47 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kathey Marsden updated DERBY-4264:
----------------------------------

    Attachment: derby-4264_10.2_diag_diff.txt

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.


Mime
View raw message