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