I think this may be a bug in messenger.
>From tracing the wire, I see that every time guru sends a reply using the
>reply_to field in the message, a completely new session and link are created.
>Over time this leads to a large number of sessions and links - one for each
>reply message sent.
The student is setting the reply_to in its request to "~/#", which causes a
uuid-based address to be substituted in the outgoing request messages' reply_to
field. For example, guru might get the following reply-to in each received
What appears to be happening is messenger on guru.rb fails to re-use an
existing 'return link' back to student, and creates a new one. I think this
is due to the way messenger marks the link as 'dynamic' and never sets the
terminus address in the new link. Thus when the next request arrives with the
same reply-to, the link resolution logic doesn't find a link with a matching
terminus address, and creates another one.
Sounds wrong to me - though honestly I'm not 100% sure I understand the purpose
of the "~/#" address semantics.
----- Original Message -----
> From: "Darryl L. Pierce" <dpie...@redhat.com>
> To: firstname.lastname@example.org
> Sent: Tuesday, April 29, 2014 11:01:45 AM
> Subject: Messenger.receive(1) causing sluggish behavior
> Using the Ruby Chatty example in my examples repo  I see painful
> slow runtime performance. To run the example, first launch the Guru
> $ ruby guru.rb
> Then, in another terminal, start a single Student instance:
> $ ruby student
> What you'll see is the student starts off with a 1 or 2 messages,
> but then immediately gets sluggish. If you start another instance of
> Student things degrade very quickly.
> If, however, in student.rb we change:
> then there is no apparently sluggishness until several thousand messages
> have been sent, and multiple instances of Student are able to run
> without slowing down.
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.