[jira] Created: (STOMP-4) STOMPConnect: Client Acknowledgment Mode loses messages in unmanaged temporary queue

STOMPConnect: Client Acknowledgment Mode loses messages in unmanaged temporary queue
------------------------------------------------------------------------------------

                 Key: STOMP-4
                 URL: http://jira.codehaus.org/browse/STOMP-4
             Project: Stomp
          Issue Type: Bug
         Environment: Windows XP SP2
.NET 2.0
STOMPConnect 1.0
TIBCO EMS 4.2.0
            Reporter: Jim Gomes


When I subscribe to a temporary queue for message reply with acknowledgment mode set to client, an extra temporary queue is created and the messages are never routed back to my STOMP client.  If I subscribe with auto-acknowledge, then everything works correctly.  Here are the steps to reproduce:

1. Connect to STOMPConnect.
2. Send SUBSCRIBE command:
{quote}
{{SUBSCRIBE}}
{{destination:/temp-queue/foo}}
{{ack:client}}

{{^@}}
{quote}

At this point, a temporary queue will be created on the TIBCO server.  TIBCO uses its own naming of temporary queues.  TIBCO created a temporary queue named {{$TMP$.EMS-SERVER.56C46A795A610D6.130}}. STOMPConnect seems to manage the mapping between my user-friendly name ({{foo}}) and TIBCO's generated name.

3. Send MESSAGE command that will be processed by mBean, and mBean will send a result message back to the temporary queue we are subscribed to:
{quote}
{{SEND}}
{{destination:/queue/mBeanQueue}}
{{reply-to:/temp-queue/foo}}
{{_other headers_}}

{{^@}}
{quote}

At this point, the mBean retrieved the message I sent to it, and processed it.  Instead of replying to the temporary queue that I subscribed to, it created a *new* temporary queue in TIBCO named {{$TMP$.EMS-SERVER.56C46A795A610D7.131}}, and posted the reply message into that queue.  STOMPConnect won't retrieve the message from this second temporary queue and send it back to me.  The message is now stuck in this queue, and there is no way to retrieve it, since I do not have a direct connection to the TIBCO-named queues.

If I unsubscribe from the {{/temp-queue/foo}} temporary queue, only the first temporary queue {{$TMP$.EMS-SERVER.56C46A795A610D6.130}} that was created by the subscription request is actually cleaned up from TIBCO.  The second temporary queue {{$TMP$.EMS-SERVER.56C46A795A610D7.131}} is now garbage, and will only be removed if I manually delete it using the TIBCO admin tool.  STOMPConnect will not clean up this second temporary queue.

If I perform the same steps above, but do not set the acknowledgment mode to client (i.e., do not include the {{ack:client}} header so it defaults to auto-acknowledge mode), then everything works correctly.  No second garbage temp-queue is created, and the result message from the mBean is posted back to the original temp-queue that I have subscribed to.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email