Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1132182

Summary:	[GSS] (6.3.1) The returnBlocking() method should propagate the exception in the fail method or RemottingConnection.
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Jimmy Wilson <jawilson>
Component:	HornetQ	Assignee:	Clebert Suconic <csuconic>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Miroslav Novak <mnovak>
Severity:	unspecified	Docs Contact:	Russell Dickenson <rdickens>
Priority:	unspecified
Version:	6.3.0	CC:	bbaranow, cdewolf, jawilson, jbertram, mnovak, msvehla, rdickens, tom.ross
Target Milestone:	CR1	Keywords:	Triaged
Target Release:	EAP 6.3.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1128804	Environment:
Last Closed:	2014-10-13 18:39:27 UTC	Type:	Enhancement
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:	1128804
Bug Blocks:	1102082, 1132169

Description Jimmy Wilson 2014-08-20 20:58:16 UTC

+++ This bug was initially created as a clone of Bug #1128804 +++

At the moment when connection fails the exception is passed to fail() method that deal with the connection failure but tho exception is not propagated tot client, it's only send to exception listeners. It would be helpful if it was pass to client via returnBlocking method.

--- Additional comment from JBoss JIRA Server on 2014-08-12 16:11:39 EDT ---

Justin Bertram <jbertram> updated the status of jira HORNETQ-1388 to Resolved

--- Additional comment from JBoss JIRA Server on 2014-08-12 16:11:49 EDT ---

Justin Bertram <jbertram> updated the status of jira HORNETQ-1388 to Closed

--- Additional comment from  on 2014-08-12 16:12:57 EDT ---

This has been resolved on the 2.3.x branch of HornetQ via 7a8e2fa11670093d34290c46e804dbd1ba51504c.

Comment 2 Martin Svehla 2014-09-01 10:05:46 UTC

We can now see in our failover tests that HornetQ is correctly returning cause exception in the error. Verified with EAP 6.3.1.CP.CR1