Bug 1097276
| Summary: | [GSS](6.4.z) MsSql datasource throws IllegalStateException while obtaining connection | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Martin Simka <msimka> | ||||||||||
| Component: | Security | Assignee: | Darran Lofthouse <darran.lofthouse> | ||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Martin Simka <msimka> | ||||||||||
| Severity: | high | Docs Contact: | Russell Dickenson <rdickens> | ||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 6.3.0 | CC: | bbaranow, bmaxwell, cdewolf, deisner, dpal, dsulliva, hokuda, istudens, jawilson, jmartisk, jolee, mharvey, myarboro, smumford, tfonteyn, tkonishi, tom.jenkinson, vvasilev, zrhoads | ||||||||||
| Target Milestone: | CR1 | Keywords: | TestCaseNeeded | ||||||||||
| Target Release: | EAP 6.4.4 | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Known Issue | |||||||||||
| Doc Text: |
This release of JBoss EAP 6 carries a bug that produces the exception; `java.lang.IllegalStateException: This ticket is no longer valid` in MySQ datasources while obtaining connection.
This issue is expected to be resolved in a future release.
|
Story Points: | --- | ||||||||||
| Clone Of: | |||||||||||||
| : | 1257226 (view as bug list) | Environment: | |||||||||||
| Last Closed: | 2017-01-17 10:49:54 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 1235744, 1256953, 1257226 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Martin Simka
2014-05-13 13:19:32 UTC
same problem with non-XA datasource. It does not happen while running single test (-Dit.test=) but it always fails with all tests task. With XA datasource it happens in both cases, all tests and single test. I will get an EAP build running in a minute, we should not be hitting any timeouts here but I am wondering if something is calling dispose on the GSSCredential and making it invalid. Created attachment 896426 [details]
MSSQL Stack Traces
Attaching a debugger I can confirm that the error message being reported is as a result of the JDBC driver disposing of the KerberosTicket that it is using and then subsequently attempting to use it again, the two stacks in the file illustrate this.
I think the following could now be beneficial: - - Update testing so that the category 'com.microsoft' is logged at level FINEST - Update the test to use ByteMan to log the stack each time javax.security.auth.kerberos.KerberosTicket.dispose() us called. My feeling at the moment is that the driver is taking a valid Subject, something during the call is causing the driver to invalidate one of the tickets and the driver subsequently tries to use it an fails. The additional logging should help map this better with the ByteMan traces as well. It could be that there is something we can fix and it is an initial connection attempt that is failing but we only see an error message for a retry or it could be an issue within the JDBC driver. Created attachment 897158 [details]
byteman-server.log
suggested changes were added to test suite, branch byteman. KerberosTicket.destroy is always called after authentication. Details in attached server.log
Created attachment 927065 [details]
byteman-two-test-connection-in-pool-calls-server.log
Attached server.log with two test-connection-in-pool calls. First passes, second fails.
com.microsoft log category set to TRACE
byteman rule that logs stack each time javax.security.auth.kerberos.KerberosTicket.destroy() us called
Don't think we already added clarification regarding the difference between XA and non-XA but simply it is the recovery thread for the XA connections that is causing the error to be reported sooner as that thread can result in an attempt to obtain a connection sooner. Kabir Khan <kabir.khan> updated the status of jira EAP6-217 to Resolved John Doyle <jdoyle> updated the status of jira EAP6-217 to Closed As per https://bugzilla.redhat.com/show_bug.cgi?id=1097276#c25 I believe the authentication cache disabling must be applied in conjunction with disabling prefill. Most likely IronJacamar fills the cache in a loop with the same Subject. If that is the case, maybe we can change that loop to always go through authentication and leave the Subject caching to the security configuration. As suggested by Derek Horton:
> Change:
>
> <security-domain name="SQLJDBC_KERBEROS" cache-type="default">
>
> to this:
>
> <security-domain name="SQLJDBC_KERBEROS">
verified with EAP 6.4.4.CP.CR3 Martin Simka <msimka> updated the status of jira JBEAP-843 to Closed Per erich, "I have been given information that EAP 6.4.4 shipped and should be available." Curious why this BZ doesn't reflect that and why it is not in closed state? Retroactively bulk-closing issues from released EAP 6.4 cumulative patches. Retroactively bulk-closing issues from released EAP 6.4 cumulative patches. |