BlazeDS Requires HTTP Session? (help!)

That helps a lot. You helped us get on the right path.

One last item...for clients using MessageService/JMSAdapter/long poll channel, I would imagine the FlexSession would establish a connection to the topic, and with pinning, the client would reuse that connection to get any topic messages that are available.

If I understand the mechanics correctly, this the general flow:

1) client connects to the FlexSession via httpsession
2) clients waits for wait-interval-millis (long poll)
3) reconnects to the same FlexSession at polling-interval-millis frequency

If the polling-interval-millis was set to, lets say, 30 seconds and in those 30 seconds (while the client is not conncted) 100 JMS messages came into the topic. Will the client receive the 100 messages when it re-connects back with the FlexSession? Or does the client have to be waiting in long poll to get the messages?

>>Can you explain a little how sessions are used (in the case of JMS)

Messaging works pretty much the same whether you are using JMS or not. A client subscribes to one or more messaging destinations on the server. There is a message queue on the server that contains all of the undelivered messages for the client. When a new message is sent to a destination and the client is subscribed to the destination, the message gets added to it's message queue. The way that messages get delivered to the client depends on the channel/endpoint that is being used. In the case of long polling, the client makes an initial poll request to the server. If there are no undelivered messages for the client, the request gets parked on the server until new messages come in.

The session is used to associate the client with the information we have about the client on the server. . . what destinations the client is subscribed to, the queue of messages to be delivered to the client over a given endpoint, etc.

I'm not sure exactly what will happen if you use a load balancer that doesn't do session pinning but things definitely will not work properly.

In the best case scenario with long polling, poll requests to a server where the client didn't have any subscriptions would just be ignored. This wouldn't be great because with your least balanced algorithm, you wouldn't be sure when the poll request would get to the right machine and the load balancer would be slowing things down at that point when you want it to speeding things up. A worse scenario would be that I think you could potentially get subscribed to the same destination on multiple servers. If that happened, the client would have a message queue on each server. The client could get duplicate messages or the queues could just hang around with the client never retrieving the messages.

Something like that could cause your memory problems. Most memory problems like this we have seen, have been due to message queues building up faster than the messages can be delivered. The message queue will usually not go away until the HTTP Sesssion times out, so a shorter HTTP Session timeout or sending messages less frequently can help with this.

>>Do you have a preferred setup/config in this case?

I think the preferred setup would be to use a load balancer that does session pinning. The clustering in BlazeDS is mostly for scalability. If two servers are clustered, a message sent to one server in the cluster will get delivered to another server in the cluster if a client is connected to the other server and should get the message (ie. if the client is subscribed to the same destination the message was sent to). You really don't need this behavior with JMS because two clients subscribed to the same JMS destination on different servers will both get a sent message through the JMS system. There is no need to send messages between BlazeDS server instances.

The clustering in BlazeDS also does some failover but this is pretty basic. If one server goes down, the client will failover to another server in the cluster but the other server won't know anything about the client's subscriptions. The client will setup these subscriptions again on it's own (ie. resubscribe to the destination(s) on the new server) but this will also happen if you are using a load balancer.

We don't do state failover currently. We don't keep things like the queue of undelivered messages in the session so you really won't get any benefit from replicating sessions.

Hope that helps.

-Alex

Thanks for the response.<br /><br />> What features of BlazeDS are you using? <br /><br />We use two AMF channels. One for normal remoting type operations and the other to receive messages from a JMS queue.<br /><br />-------------<br /><service id="remoting-service" class="flex.messaging.services.RemotingService"><br /> <adapters><br /> <adapter-definition id="java-object" class="flex.messaging.services.remoting.adapters.JavaAdapter" default="true" /><br /> </adapters><br /><channels><br /> <channel ref="nrt-amf" /><br /> </channels><br />-------------<br /><br /> <service id="message-service" class="flex.messaging.services.MessageService"><br /><br /> <adapters><br /> <adapter-definition id="jms" class="flex.messaging.services.messaging.adapters.JMSAdapter" /><br /> </adapters><br /><channels><br /> <channel ref="nrt-amf-polling" /><br /> </channels><br />-------------<br /><channel-definition id="nrt-amf" class="mx.messaging.channels.AMFChannel"><br /> <endpoint url="http://somwhere:80/messagebroker/nrtamf" class="flex.messaging.endpoints.AMFEndpoint" /><br /> <properties><br /><br /> <serialization><br /> <legacy-collection>true</legacy-collection><br /> </serialization><br /><polling-enabled>false</polling-enabled><br /><br />-------------<br /><channel-definition id="nrt-amf-polling" class="mx.messaging.channels.AMFChannel"><br /> <endpoint url="http://somewhere:80/messagebroker/nrtamfpolling" class="flex.messaging.endpoints.AMFEndpoint" /><br /> <properties><br /> <br /> <serialization><br /> <legacy-collection>true</legacy-collection><br /> </serialization> <polling-enabled>true</polling-enabled><br /><wait-interval-millis>60000</wait-interval-millis><br /><max-waiting-poll-requests>2550</max-waiting-poll-requests><br /><polling-interval-millis>0</polling-interval-millis><br />-------------<br /><br />> Your clients are just browsers? <br /><br />Yes.<br /><br />> Are you using a load balancer or something to route requests to different servers?<br /><br />Yes. At the moment, it uses a least connection algorithm to balance requests across systems. No session / transport layer work is being done there. No pinning or sticky sessions.<br /><br />I have a feeling that since our JMS connection uses long polling, and each reconnect may get a different server, there is some wasted session/connection overhead with our current setup. We are seeing memory problems (likely http://www.adobeforums.com/webx/.59b5bc91 or some other inefficency)<br /><br />- Can you explain a little how sessions are used (in the case of JMS)<br /><br />- Do you have a preferred setup/config in this case? I noticed that there is a blaze clustering option (would that do session replication?) If sessions are required, we'd like to ensure session efficiency and provide state failover as well.

Hi. What features of BlazeDS are you using? The messaging service requires sessions to work properly. If your request goes to another server instance, that instance won't know about your subscription state.

I guess if you were just making RemoteObject calls the session wouldn't matter as much but as you found out it looks like we do require sessions currently (although not cookies).

Can you tell me some more about your setup? Your clients are just browsers? Are you using a load balancer or something to route requests to different servers? And that load balancer or whatever is stateless and not using sticky sessions to pin a client to a particular server?

If you feel there is a valid use case for being able to disable session detection you can add an enhancement request in our bug database:

http://opensource.adobe.com/wiki/display/blazeds/Bugbase

-Alex