[
https://issues.apache.org/activemq/browse/AMQ-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Schwamb updated AMQ-3015:
------------------------------
Description:
In some configurations, the javascript client (amq.js) is not loaded from the
same container that hosts the activemq broker. For example, we have a Rails
app and ActiveMQ both sitting behind apache, and the amq.js file is served
directly by apache.
In these kinds of configurations, when the javascript client first calls
amq.init(), there is no JSESSIONID. Both the POST to establish the
subscription and the GET to start polling are delivered asynchronously, both
without a JSESSIONID, and thus they each end up with different JSESSIONIDS, and
the poll never returns any messages (as that session has no subscription).
This small patch adds support for a callback mechanism that will allow clients
to sign up using a callback mechanism that ensures that the JESSIONID is
established properly before attempting to make a subscription, like this:
{code:javascript:title=myclient.js|borderStyle=solid}
amq.init({
uri: '/amq',
sessionInitializedCallback: function() {
amq.addListener("display", "topic://sensors", onMessage);
}
});
{code}
The patch is also backwards compatible, so existing code should still work
(albeit with the same existing problem).
was:
In some configurations, the javascript client (amq.js) is not loaded from the
same container that hosts the activemq broker. For example, we have a Rails
app and ActiveMQ both sitting behind apache, and the amq.js file is served
directly by apache.
In these kinds of configurations, when the javascript client first calls
amq.init(), there is no JSESSIONID. Both the POST to establish the
subscription and the GET to start polling are delivered asynchronously, both
without a JSESSIONID, and thus they each end up with different JSESSIONIDS, and
the poll never returns any messages (as that session has no subscription).
This small patch adds support for a callback mechanism that will allow clients
to sign up using a callback mechanism that ensures that the JESSIONID is
established properly before attempting to make a subscription, like this:
amq.init({
uri: '/amq',
sessionInitializedCallback: function() {
amq.addListener("display", "topic://sensors", onMessage);
}
});
> Javascript client does not establish session properly.
> ------------------------------------------------------
>
> Key: AMQ-3015
> URL: https://issues.apache.org/activemq/browse/AMQ-3015
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.4.1
> Reporter: Pete Schwamb
> Attachments: amq_session.patch
>
>
> In some configurations, the javascript client (amq.js) is not loaded from the
> same container that hosts the activemq broker. For example, we have a Rails
> app and ActiveMQ both sitting behind apache, and the amq.js file is served
> directly by apache.
> In these kinds of configurations, when the javascript client first calls
> amq.init(), there is no JSESSIONID. Both the POST to establish the
> subscription and the GET to start polling are delivered asynchronously, both
> without a JSESSIONID, and thus they each end up with different JSESSIONIDS,
> and the poll never returns any messages (as that session has no subscription).
> This small patch adds support for a callback mechanism that will allow
> clients to sign up using a callback mechanism that ensures that the JESSIONID
> is established properly before attempting to make a subscription, like this:
> {code:javascript:title=myclient.js|borderStyle=solid}
> amq.init({
> uri: '/amq',
> sessionInitializedCallback: function() {
> amq.addListener("display", "topic://sensors", onMessage);
> }
> });
> {code}
> The patch is also backwards compatible, so existing code should still work
> (albeit with the same existing problem).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
