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

Bug 1135460

Summary: [QE] (6.3.1) Server cannot be cleanly shut-downed with suspended subscriber
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Miroslav Novak <mnovak>
Component: HornetQAssignee: Andy Taylor <ataylor>
Status: CLOSED DUPLICATE QA Contact: Miroslav Novak <mnovak>
Severity: medium Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.3.0, 6.3.1CC: ataylor, jbertram, mnovak, msvehla
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-08 06:33:05 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:
Attachments:
Description Flags
threaddump.txt none

Description Miroslav Novak 2014-08-29 11:38:24 UTC 
Description of problem:
Server with suspended subscriber cannot be cleanly shut-downed. 

Steps to Reproduce:
1.Start Broker, with a configured topic
2.Start the topic subscriber, that will continually (in a while true loop) consume topic messages
3.Start the topic publisher, that will continually (in a while true loop) produce topic messages
4.Pause the subscriber (with kill -STOP)
5.Try cleanly (ctrl-c) shut-down the server

Actual results:
Sever hangs. When subscriber is "unpaused" (by kill -CONT) then server shutdowns.
Comment 1 Justin Bertram 2014-08-29 18:32:07 UTC 
Couple of questions...

  1) If you wait for the connection-ttl to elapse what happens?
  2) Can you attach a thread dump from when the server is waiting to shut-down?
Comment 2 Miroslav Novak 2014-09-01 06:19:53 UTC 
1) When subscriber is paused then server prints:
08:15:47,884 WARN  [org.hornetq.core.client] (hornetq-failure-check-thread) HQ212037: Connection failure has been detected: HQ119014: Did not receive data from /127.0.0.1:36757. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
08:15:47,885 WARN  [org.hornetq.core.server] (hornetq-failure-check-thread) HQ222061: Client connection failed, clearing up resources for session 31a0f2d8-319f-11e4-a21e-a31062cb8a68
08:15:47,886 WARN  [org.hornetq.core.server] (hornetq-failure-check-thread) HQ222107: Cleared up resources for session 31a0f2d8-319f-11e4-a21e-a31062cb8a68
08:15:47,886 WARN  [org.hornetq.core.server] (hornetq-failure-check-thread) HQ222061: Client connection failed, clearing up resources for session 31a64a09-319f-11e4-a21e-a31062cb8a68

which did not happen before and indicates that subscriber was disconnected.

2) I've attached the thread dump.
Comment 3 Miroslav Novak 2014-09-01 06:20:17 UTC 
Created attachment 933245 [details]
threaddump.txt
Comment 4 Andy Taylor 2014-09-01 14:28:36 UTC 
The issue is that there is a thread stuck in a socket write, it looks like the TCP layer is just trying to resent the packet. The failure thread is trying to set the server session to setstarted(false) which gets stuck as it uses the deliveryWrite lock that is loocked. This in turn stops the servers closing thread from completing as it joins on the failurethread.

Myself or Justin will investigate further
Comment 5 Miroslav Novak 2014-09-02 13:02:21 UTC 
We should close this bz. After investigation it appears to be duplicate of original bz [1] and continue with investigation there. 

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1132189
Comment 6 Miroslav Novak 2014-09-08 06:33:05 UTC 
Closing as this appears to be duplicate.

*** This bug has been marked as a duplicate of bug 1132189 ***