Bug 1003913 - JMSService.start is doing blocking I/O
Summary: JMSService.start is doing blocking I/O
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JMS
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER3
: EAP 6.2.0
Assignee: Jeff Mesnil
QA Contact: Miroslav Novak
Russell Dickenson
URL:
Whiteboard:
: 974942 1009530 (view as bug list)
Depends On: 974942
Blocks: 996500 1082103
TreeView+ depends on / blocked
 
Reported: 2013-09-03 13:50 UTC by Jeff Mesnil
Modified: 2014-03-28 16:50 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
: 1082103 (view as bug list)
Environment:
Last Closed: 2013-12-15 16:55:50 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-101 0 Major Closed JMSService.start is doing blocking I/O 2018-08-07 05:38:06 UTC

Description Jeff Mesnil 2013-09-03 13:50:44 UTC 
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 15:37:31 UTC 
*** Bug 1009530 has been marked as a duplicate of this bug. ***
Comment 3 Jeff Mesnil 2013-09-18 15:49:05 UTC 
*** Bug 974942 has been marked as a duplicate of this bug. ***
Comment 5 Miroslav Novak 2013-10-07 13:01:30 UTC 
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 07:08:00 UTC 
(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 09:08:52 UTC 
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 09:15:04 UTC 
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 16:15:05 UTC 
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.