Thanks Seth, That did the trick.
--- In [email protected], "Seth Hodgson" <[EMAIL PROTECTED]> wrote:
>
> Hi Satish,
>
> The <wait-interval-millis> setting controls how long the server will
park a poll request and wait for something to return. With a wait of
just 100 ms, the server will return an empty poll response to the
client almost immediately. Try increasing this setting to 60000 (1
minute).
>
> Also, HTTP 1.1 connections don't close when a response is returned
to the client. Connections are persistent by default, and will be
closed by the user agent after a period of inactivity.
>
> Seth
>
> From: [email protected] [mailto:[EMAIL PROTECTED]
On Behalf Of Satish Kore
> Sent: Thursday, May 29, 2008 12:29 PM
> To: [email protected]
> Subject: [flexcoders] BlazeDS Long Polling Question
>
> Hello All,
>
> I am bit confused about Long polling in BlazeDS, as far as I
understand long polling technique that is Long-polling sends a request
to the server, but a response is not returned to the client until one
is available. As soon as the connection is closed, either due to a
response being received by the client or if a request times out, a new
connection is initiated. Now by this definition I assume that once
request is sent to server it holds it until some response data is
available and then it returns that requests and waits for next long
polling request.
> But when I tried using debugging tool like ServiceCapture to capture
long polling requests in BlazeDS it shows that requests are sent to
server every 10ms or so and server does not hold that connection
instead it returns with 200 OK http response code almost immediately,
Now I don't understand this but I am pretty sure that this is wrong.
Could anybody please let me know what is that I am missing here?
Following is my long polling channel definition
>
> <channel-definition id="my-longpolling-amf"
class="mx.messaging.channels.AMFChannel">
> <endpoint
url="http://{server.name}:{server.port}/{context.root}/messagebroker/amflongpolling";
class="flex.messaging.endpoints.AMFEndpoint"/>
> <properties>
>
<polling-enabled>true</polling-enabled>
>
<polling-interval-seconds>-1</polling-interval-seconds>
>
<wait-interval-millis>100</wait-interval-millis>
>
<client-wait-interval-millis>1</client-wait-interval-millis>
>
<max-waiting-poll-requests>50</max-waiting-poll-requests>
> </properties>
> </channel-definition>
> I don't think there is any problem in above configuration but I am
unable to understand this request and response model in long polling
context. Check attached screen shot of ServiceCapture in action.
> Thanks,
> Satish Kore
> http://blog.satishkore.com
>
