Bug 995492 - Mcollective plugin disconnects from Stomp after each call
Summary: Mcollective plugin disconnects from Stomp after each call
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 1.2.0
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: Brenton Leanhardt
QA Contact: libra bugs
URL:
Whiteboard:
Depends On: 892764
Blocks: 995498
TreeView+ depends on / blocked
 
Reported: 2013-08-09 14:20 UTC by Jan Pazdziora
Modified: 2017-03-08 17:35 UTC (History)
10 users (show)

Fixed In Version: mcollective-2.2.1-5.el6op
Doc Type: Bug Fix
Doc Text:
Due to a bug in the Stomp connector in previous versions of Mcollective, connections were not opening and closing correctly. This has been fixed and connections now open and close as expected.
Clone Of: 892764
Environment:
Last Closed: 2013-09-25 15:30:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1275 0 normal SHIPPED_LIVE OpenShift Enterprise 1.2.3 bug fix and enhancement update 2013-09-25 19:26:23 UTC

Description Jan Pazdziora 2013-08-09 14:20:47 UTC
+++ This bug was initially created as a clone of Bug #892764 +++

Description of problem:
Broker code on F17 does not work with latest version of stomp (1.2.8)

Version-Release number of selected component (if applicable):
Fedora 17, Stomp 1.2.8, Ruby 1.9

How reproducible:
Always

Steps to Reproduce:
1. Configure m-collective plugin to use stomp 1.2.8
2. Restart broker
3. Perform any mcollective api call to get results from node
  
Actual results:
No existing connection error

Expected results:
API call succeeds

Additional info:
Code works with Stomp 1.2.2

--- Additional comment from Krishna Raman on 2013-01-08 01:55:08 CET ---

Traced this some more and the reason its failing is because we are disconnecting the stomp connection after a call is made to the node.

Before patch https://github.com/puppetlabs/marionette-collective/pull/56, the connection was never re-established and any calls made after the initial disconnect would fail.

I have asked Troy to patch and provide a version of the F18 mcollective 2.2 RPM on the mirror site and this seems to have fixed the problem.

--- Additional comment from Laurent Eschenauer on 2013-02-08 15:34:51 CET ---

I have a similar problem with the openshift origin broker on CentOS 6.3. On every request, I receive a "no current connection exists" error (full stack trace below).

I've just checked, and the openshift infrastructure repo still contains the mcollective-client 2.0 and not 2.2. Could this be the issue ?

Ruby 1.8.7
Stomp 1.2.2
openshift-origin-broker-1.0.1

Installed following the 'build your own paas' tutorial.


Snipet from development.log:

Started GET "/broker/rest/cartridges" for 192.168.100.8 at Thu Feb 07 21:11:59 +0000 2013
  Processing by CartridgesController#index as JSON
Completed 500 Internal Server Error in 7ms

Stomp::Error::NoCurrentConnection (no current connection exists):
  

Rendered /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/templates/rescues/_trace.erb (1.3ms)
Rendered /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/templates/rescues/_request_and_response.erb (3.3ms)
Rendered /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/templates/rescues/diagnostics.erb within rescues/layout (7.1ms)

--- Additional comment from Krishna Raman on 2013-02-08 15:45:37 CET ---

Yes, that is the exact symptom of this issue. If you apply the changes mentioned in the mcollective patch in comment #1, you should be able to work around it.

(In reply to comment #2)
> I have a similar problem with the openshift origin broker on CentOS 6.3. On
> every request, I receive a "no current connection exists" error (full stack
> trace below).
> 
> I've just checked, and the openshift infrastructure repo still contains the
> mcollective-client 2.0 and not 2.2. Could this be the issue ?
> 
> Ruby 1.8.7
> Stomp 1.2.2
> openshift-origin-broker-1.0.1
> 
> Installed following the 'build your own paas' tutorial.
> 
> 
> Snipet from development.log:
> 
> Started GET "/broker/rest/cartridges" for 192.168.100.8 at Thu Feb 07
> 21:11:59 +0000 2013
>   Processing by CartridgesController#index as JSON
> Completed 500 Internal Server Error in 7ms
> 
> Stomp::Error::NoCurrentConnection (no current connection exists):
>   
> 
> Rendered
> /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/
> templates/rescues/_trace.erb (1.3ms)
> Rendered
> /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/
> templates/rescues/_request_and_response.erb (3.3ms)
> Rendered
> /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/
> templates/rescues/diagnostics.erb within rescues/layout (7.1ms)

--- Additional comment from Laurent Eschenauer on 2013-02-08 15:59:57 CET ---

Thank you, I've applied the patch and it fixes the problem.

Note that I've tried to install mcollective 2.2 from the puppetlabs repo, and this causes other errors in the broker.

(In reply to comment #3)
> Yes, that is the exact symptom of this issue. If you apply the changes
> mentioned in the mcollective patch in comment #1, you should be able to work
> around it.
> 
> (In reply to comment #2)
> > I have a similar problem with the openshift origin broker on CentOS 6.3. On
> > every request, I receive a "no current connection exists" error (full stack
> > trace below).
> > 
> > I've just checked, and the openshift infrastructure repo still contains the
> > mcollective-client 2.0 and not 2.2. Could this be the issue ?
> > 
> > Ruby 1.8.7
> > Stomp 1.2.2
> > openshift-origin-broker-1.0.1
> > 
> > Installed following the 'build your own paas' tutorial.
> > 
> > 
> > Snipet from development.log:
> > 
> > Started GET "/broker/rest/cartridges" for 192.168.100.8 at Thu Feb 07
> > 21:11:59 +0000 2013
> >   Processing by CartridgesController#index as JSON
> > Completed 500 Internal Server Error in 7ms
> > 
> > Stomp::Error::NoCurrentConnection (no current connection exists):
> >   
> > 
> > Rendered
> > /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/
> > templates/rescues/_trace.erb (1.3ms)
> > Rendered
> > /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/
> > templates/rescues/_request_and_response.erb (3.3ms)
> > Rendered
> > /usr/lib/ruby/gems/1.8/gems/actionpack-3.0.13/lib/action_dispatch/middleware/
> > templates/rescues/diagnostics.erb within rescues/layout (7.1ms)

--- Additional comment from Krishna Raman on 2013-03-22 21:20:06 CET ---

Fixed by providing custom build of m-collective with patch applied.

--- Additional comment from Peter Ruan on 2013-03-26 20:41:35 CET ---

verified with the latest origin build.  I don't see this error anymore.

Comment 1 Jan Pazdziora 2013-08-09 14:22:50 UTC
I attempt to use OpenShift Enterprise 1.2 with stomp 1.2.2 (to be able to use SSL) and I've hit what seems to be the same symptoms as described here for Origin. Applying

https://github.com/tarhashi/marionette-collective/commit/2ed4a5839667b64e2c94100a644de1083cc4a263

to my

   /opt/rh/ruby193/root/usr/libexec/mcollective/mcollective/connector/activemq.rb /opt/rh/ruby193/root/usr/libexec/mcollective/mcollective/connector/stomp.rb

(of ruby193-mcollective-common-2.2.1-4.el6op.noarch) makes things work. Could the ruby193-mcollective-common in Enterprise be patched to contain the fix?

Comment 4 Johnny Liu 2013-08-20 11:17:41 UTC
If test this bug against ose puddle, need scl stomp gem package.

Comment 5 Brenton Leanhardt 2013-08-20 13:18:59 UTC
The ose puddle should have ruby193-rubygem-stomp-1.1.8-1.el6op.noarch.

I believe Jan is using a newer version of stomp.  If he can verify this patched mcollective works for him I would be willing to consider upgrading the version of stomp for OSE as long as it passes our test.

Comment 6 Johnny Liu 2013-08-21 02:29:45 UTC
Agree, (In reply to Brenton Leanhardt from comment #5)
> The ose puddle should have ruby193-rubygem-stomp-1.1.8-1.el6op.noarch.
Yes, the package that ose puddle ship is an older package than the one Jan is using.
> 
> I believe Jan is using a newer version of stomp.  If he can verify this
> patched mcollective works for him I would be willing to consider upgrading
> the version of stomp for OSE as long as it passes our test.

Agree.

Comment 10 Johnny Liu 2013-09-06 10:56:51 UTC
@Brenton, currently ose puddle is shipping ruby193-rubygem-stomp-1.2.2-1.el6op.noarch, not stomp 1.2.8.

In the initial description, this bug does not exit with stomp 1.2.2, but reproduce with stomp 1.2.8.

Should we ship the latest stomp 1.2.8, ma I right?

Comment 11 Brenton Leanhardt 2013-09-06 13:09:24 UTC
Ahh, and I see that in Bug #995498 even though 1.2.2 or greater was requested it appears the user was actually using 1.2.11.  I'll try updating to that version.

Comment 12 Brenton Leanhardt 2013-09-06 13:57:12 UTC
Version 1.2.14 will ship with the next puddle.

Comment 13 Gaoyun Pei 2013-09-09 08:34:29 UTC
Verify this bug with package ruby193-rubygem-stomp-1.2.14-1.el6op.noarch on puddle 1.2/2013-09-06.1

stomp 1.2.14 works well on OSE env, no errors found.

Comment 16 errata-xmlrpc 2013-09-25 15:30:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1275.html


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