Bug 1003913 - JMSService.start is doing blocking I/O
JMSService.start is doing blocking I/O
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JMS (Show other bugs)
6.1.0
Unspecified Unspecified
unspecified Severity unspecified
: ER3
: EAP 6.2.0
Assigned To: Jeff Mesnil
Miroslav Novak
Russell Dickenson
:
: 974942 1009530 (view as bug list)
Depends On: 974942
Blocks: 996500 1082103
  Show dependency treegraph
 
Reported: 2013-09-03 09:50 EDT by Jeff Mesnil
Modified: 2014-03-28 12:50 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1082103 (view as bug list)
Environment:
Last Closed: 2013-12-15 11:55:50 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-101 Major Resolved JMSService.start is doing blocking I/O 2017-06-16 00:59 EDT

  None (edit)
Description Jeff Mesnil 2013-09-03 09:50:44 EDT
Description of problem:

JMSService.start is doing blocking I/O which is forbidden by the MSC service contract.
Comment 2 Jeff Mesnil 2013-09-18 11:37:31 EDT
*** Bug 1009530 has been marked as a duplicate of this bug. ***
Comment 3 Jeff Mesnil 2013-09-18 11:49:05 EDT
*** Bug 974942 has been marked as a duplicate of this bug. ***
Comment 5 Miroslav Novak 2013-10-07 09:01:30 EDT
Hi Jeff, 

could you help with verification of this bz, please? I can see that PR contains actually more than one thing. "HornetQ fail-back results in XA recovery warnings" I can verify easily.

Problem is "[WFLY-101] JMSService.start to perform blocking I/O asynchronously" I guess only way to verify is to read the code, right?
Comment 7 Jeff Mesnil 2013-10-08 03:08:00 EDT
(In reply to Miroslav Novak from comment #5)
> Problem is "[WFLY-101] JMSService.start to perform blocking I/O
> asynchronously" I guess only way to verify is to read the code, right?

That's correct, there is no observable way to verify this.
Reading the code, it appears that the JMSService.start/stop methods performs HornetQ-related operations asynchronously in a separate executor: https://github.com/jmesnil/jboss-eap/commit/161295de1ae35a10c53dcc8f4fce933b4baadeb2#diff-60f2c56b6f01bb06387cbe9054ddc549R89
Comment 9 Miroslav Novak 2013-10-09 05:08:52 EDT
Hi Jeff,

I tried to use debugger to hold start of HornetQ - line break point was HornetQServerImpl.start line 404. But I didn't see other services to start when debugger stopped initialization of HornetQ. My understanding is that those services should start when they do not have dependency on messaging. Is it right?

Thanks,

Mirek
Comment 10 Jeff Mesnil 2013-10-09 05:15:04 EDT
Breakpoint should be on org.hornetq.jms.server.impl.JMSServerManagerImpl#start

That the HornetQ class that is called by WildFly JMSService.

I'm nto sure what should happen exactly but since the JMS server start is asynchrounous now, other WildFly services will be able to start without being blocked.
This changes nothing for services *depending* on JMSService. They will not be started until the JMSService is started (asynchronously or not).
Comment 11 Miroslav Novak 2013-10-09 12:15:05 EDT
I could not verify this BZ using debugger but based on code review (also from D. Loyd) this fix is ok.

Verified in EAP 6.2.0.ER3.

Note You need to log in before you can comment on or make changes to this bug.