Bug 1093128

Summary: [GSS](6.3.0) Remote client transaction timeout values are overwritten by hardcoded values
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Stephen Fikes <sfikes>
Component: EJBAssignee: Ivo Studensky <istudens>
Status: CLOSED CURRENTRELEASE QA Contact: Jan Martiska <jmartisk>
Severity: unspecified Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.1.1CC: bmaxwell, istudens, kkhan, ochaloup, smumford
Target Milestone: ER6   
Target Release: EAP 6.3.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Previous releases of JBoss EAP 6 carried an issue that may have resulted in remote client transactions spanning multiple servers timing out earlier or later than expected. The issue arised because timeout values are not propagated across servers correctly, leaving the system to rely on the hardcoded timeout value (300 seconds). This issue is resolved in JBoss EAP 6.3.0.
Story Points: ---
Clone Of:
: 1093752 (view as bug list) Environment:
Last Closed: 2014-06-28 15:25:07 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:
Bug Depends On:    
Bug Blocks: 1093752, 1159058    

Description Stephen Fikes 2014-04-30 16:56:44 UTC
Description of problem:
See https://issues.jboss.org/browse/WFLY-2789

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 1 Ivo Studensky 2014-05-27 10:58:48 UTC
PR sent:

Comment 2 Jan Martiska 2014-06-10 11:34:22 UTC
Verified in EAP 6.3.0.ER7.

Comment 3 Jan Martiska 2014-07-02 08:23:59 UTC
Hi Scott, I changed the doc to reflect that this is a bugfix, not a known issue in EAP 6.3.0. Could you make sure this change gets reflected in the next build of release notes? Thanks.

Comment 4 Stephen Fikes 2016-04-29 20:28:11 UTC
The resolution of this issue was to change the hardcoded timeout from 300 seconds (5 minutes) to Integer.MAX_VALUE.

Comment 5 Stephen Fikes 2016-04-29 20:29:08 UTC
See also https://bugzilla.redhat.com/show_bug.cgi?id=1265300 for a subsequent refinement.