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 04:20: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

The attached diff derby-4264_10.2_diag_diff.txt has the 10.2 diagnostic changes that that
I plan to send to the user that is seeing this issue.  They now have a test system where they
can reproduce the failure after several days run and will run with this sane modified build.

This is *not* for commit.   The change will dump the class file and information about the
GeneratedMethod and the object returned if orderableGetter.invoke(activation) returns an unexpected
type object.   It also can be run with derby.debug.true=DERBY-4264_Always to always dump this
information even if the expected type is returned.  Sample output in derby.log looks something
like:
DEBUG orderableGetterInvoke(),orderableGetter OUTPUT: DirectCall: which=1(e1())

DEBUG orderableGetterInvoke(), orderableCacheObject OUTPUT: org.apache.derby.iapi.types.SQLChar:2be1347d-2001-0000-0080-8cd524f0d033

DEBUG orderableGetterInvoke(), this OUTPUT: columnId: 3
operator: 2
orderedNulls: false
unknownRV: false
negateCompareResult: false
variantType: 3

DEBUG ReflectGeneratedClass this.toString() OUTPUT: 
ReflectGeneratedClass.getName()=org.apache.derby.exe.ac601a400fx0122x1f0dx1cdax0000001f2c580
factoryClass=null

2009-06-27 00:11:09.500 GMT Thread[main,5,main] Wrote class org.apache.derby.exe.ac601a400fx0122x1f0dx1cdax0000001f2c580
to file .\ac601a400fx0122x1f0dx1cdax0000001f2c580.class

In order to dump the class file at this late point in processing I had to pass the ByteArray
for the class data to LoadGeneratedClass  when it is created  so that the ByteArray is  preserved.
 ( I didn't know how to get the byte code back out after it had been converted to a class
with defineClass.  If the problem is actually in the conversion then we won't see that unless
we can figure out a way to retreive the byte code directly from the class.

Please take a look and let me know if there is anything else useful that we could print out
to help diagnose this issue.   There is some significant effort and time associated with getting
a run so I want to avoid additional round trips if possible.


> 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
>
>
> 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