 |
History
| Log In
|
|
|
|
You summarized it well. I included some extra information in resources/config/services-config.xml for this with changes 849 and 850 on 3.0.x and trunk branches:
"Note that streaming channels might not work through some proxy servers due to proxy buffering of chunked responses used by streaming channels. Therefore it is a best practice to use a polling channel as a backup for a streaming channel and set connect-timeout-seconds of streaming channel to a reasonable value (eg. 5 secs) so that the streaming channel can fall back to polling channel in a reasonable amount of time." Mike, could you please make sure my previous comment is included in the docs? Thanks.
Since this issue is a result of how the proxy (mod_jk in this instance) is implemented it is not something that can be corrected. Therefore using the Streaming AMF channel is not an option with Apache fronting Tomcat. I would need to expose Tomcat directly or front it with another web server whose connector is more compatible with the Streaming AMF channel. Does this sound correct? Are they any other options I'm overlooking. Thanks.
Streaming AMF/HTTP channels are definitely not an option where there is a proxy between the app server and the client and that proxy buffers chunked HTTP responses. In that case, you would want to fault back to polling as described before.
Added the following note tfrom Mete o the FrameMaker source and to the BlazeDS Livedocs:
Some proxy servers buffer messages. When streaming HTTP-based channels (both steaming AMF and HTTP channels) are used through a proxy server that does buffering, messages are not delivered immediately but rather in chunks, which defeats the purpose of streaming channels. In that case, instead of having a semi-working streaming channel, it is a better option to fall back to a polling channel. When you do use streaming channels, use a polling channel as the fallback channel and specify connect-timeout-seconds to something reasonable for your environment (for exampple, five seconds). With a short connect-timeout-seconds value, a streaming channel can detect that there is buffering and it can fall back on the polling channel. Here's the page in the BlazeDS Livedocs: http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=messaging_framework_4.html I am facing a similar problem with mod_jk and BlazeDS and i did not use a streaming channel but a normal long-polling channel. Got my sys admin to tune the mod_jk and tomcat, but still no improvements. It only works well when the Tomcat is public facing
I get this message on my apache error_log: Tue Jul 22 18:51:59 2008] [error] [client <ip address>] client denied by server configuration: amfsecure, referer: https://www.somedomain.com/myFlexApp.swf Can I say that BlazeDS does not work well with a Apache Fronting Tomcat? I am looking into exposing Tomcat directly but having only one machine makes this tough. Is there anyone who can suggest a better connector if there is one? I may be wrong but I understood that the "bug" still exist and the workaround is to well set the connect-timeout-seconds in order to switch to the polling mode.
But, in this case, is it impossible to use the AMF streaming mode if an apache server is use as a frontend for security and load balancing ? For production systems is is mandatory to expose the tomcat server ? Or is it a mod_jk issue ? It looks I paraphrase Kenneth but as I face the same issue I really wonder if I should forget the streaming mechanism as in production, my company deployment "rules" forbid me to expose a Tomcat server. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Messaging Channels do not work when port not present in browser URL and forwarded from Apache HTTP to Tomcat
The only real workaround for this is to have a polling channel as a backup so if the streaming channel can't connect fall back to polling. The streaming channel needs to have the connect-timeout-seconds property set, so if we can't connect within the given time limit we will fall back to another channel.
<channel-definition class="mx.messaging.channels.StreamingAMFChannel" id="qa-streaming-amf">
<endpoint class="flex.messaging.endpoints.StreamingAMFEndpoint" url="http://{server.name}:{server.port}/{context-root}/messagebroker/streaming-amf"></endpoint>
<properties>
<server-to-client-heartbeat-millis>500</server-to-client-heartbeat-millis>
<max-streaming-clients>10</max-streaming-clients>
<connect-timeout-seconds>5</connect-timeout-seconds>
</properties>
</channel-definition>
I'm marking this as a doc bug because I think the documentation on the streaming channels needs to get updated to included information on this as it's an issue users are likely to encounter. I also think the samples app should have connect-timeout-seconds set on the streaming amf channel.