Open gavinking opened 3 years ago
it's an issue I was not aware of and that is specific to DB2, I believe we need to engage with somebody familiar.
I'll start taking a look at this.
thank you Mark
On Tue, Feb 23, 2021 at 4:43 PM Mark Swatosh notifications@github.com wrote:
I'll start taking a look at this.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/eclipse-vertx/vertx-sql-client/issues/899#issuecomment-784295171, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCXSCPOKWFCDDKSTZUTTAPEL7ANCNFSM4YAP2FUQ .
@mswatosh any progress on this ?
@mswatosh have you had the chance to investigate this one ?
It looks like the issue here is sometimes we haven't received the full response over the network, so this method (ensureALayerDataInBuffer) needs to be updated to 'wait' for enough of the response to continue, but without blocking the thread.
FYI: This error reappeared after these changes: https://github.com/eclipse-vertx/vertx-sql-client/pull/1204
I tried this test locally and I'm able to see the issue. It doesn't appear to be intermittent, it occurs consistently for me, even if I reduce the test case to:
test(
context,
getMutinySessionFactory()
.withTransaction( (session, transaction) -> session.persistAll( author ) )
.chain( () -> getMutinySessionFactory()
.withTransaction( (session, transaction) -> session.find( Author.class, author.id )
What's interesting is from this point if I remove either of the .withTransaction statements the test passes.
I'm also seeing a couple of additional exceptions:
Cause 2: java.lang.IllegalStateException: Invalid correlator ID. Got 2 expected 1
at io.vertx.db2client.impl.drda.DRDAResponse.readDssHeader(DRDAResponse.java:946)
at io.vertx.db2client.impl.drda.DRDAResponse.startSameIdChainParse(DRDAResponse.java:52)
at io.vertx.db2client.impl.drda.DRDAQueryResponse.readExecuteImmediate(DRDAQueryResponse.java:230)
at io.vertx.db2client.impl.codec.SimpleQueryCommandCodec.decodeUpdate(SimpleQueryCommandCodec.java:57)
at io.vertx.db2client.impl.codec.QueryCommandBaseCodec.decodePayload(QueryCommandBaseCodec.java:71)
at io.vertx.db2client.impl.codec.DB2Decoder.decodePayload(DB2Decoder.java:79)
at io.vertx.db2client.impl.codec.DB2Decoder.decode(DB2Decoder.java:52)
as well as
Caused by: java.lang.IllegalStateException: Found unknown codepoint: 0x2411 / 9233
at io.vertx.db2client.impl.drda.DRDAResponse.throwUnknownCodepoint(DRDAResponse.java:847)
at io.vertx.db2client.impl.drda.DRDAQueryResponse.parseExecuteImmediateError(DRDAQueryResponse.java:1217)
at io.vertx.db2client.impl.drda.DRDAQueryResponse.parseEXCSQLIMMreply(DRDAQueryResponse.java:1174)
at io.vertx.db2client.impl.drda.DRDAQueryResponse.readExecuteImmediate(DRDAQueryResponse.java:231)
at io.vertx.db2client.impl.codec.SimpleQueryCommandCodec.decodeUpdate(SimpleQueryCommandCodec.java:57)
at io.vertx.db2client.impl.codec.QueryCommandBaseCodec.decodePayload(QueryCommandBaseCodec.java:71)
at io.vertx.db2client.impl.codec.DB2Decoder.decodePayload(DB2Decoder.java:79)
The strange thing about the last exception is 0x2411 is a SQLDARD command, which is being parsed as a response to an EXCSQLIMM command. If I look at the wireshark trace, all of the EXCSQLIMM are receiving ENDUOWNM like they should.
So I think the issue here might be the response packets are getting mixed up and ending up at the wrong Db2Decoder.
What's interesting is from this point if I remove either of the .withTransaction statements the test passes.
Interesting indeed. The second transaction is actually optional but now I don't want to change it if it makes db2 fail :)
We can refactor the tests. Anyway, let us know if we can help on the Hibernate Reactive front
FYI: In Hibernate Reactive, more tests are failing because of this error after the upgrade to ORM 6.2.
In the HR test suite I had to disable a test, as seen here:
https://github.com/hibernate/hibernate-reactive/blob/2ff95a963d18c863853f6258490d4ace341eb00c/hibernate-reactive-core/src/test/java/org/hibernate/reactive/OrderedEmbeddableCollectionTest.java#L32
because of an intermittent error that only occurred on DB2 when running the whole test suite (and not the single test).
From the error message it looks like this is something y'all know about already.