|
Dwr 2.0.3, reverseAjaxEnabled and IE6
Hi,
I've a strange behaviour with dwr 2.0.3 on page with reverse ajax enabled on IE6.
and this parameter :
<init-param>
<param-name>maxWaitAfterWrite</param-name>
<param-value>500</param-value>
</init-param>
My App is a standart struts app.
If I get on a page with reverse ajax enabled, and then click any another link, it takes about a minute to achieve the action.
This does not happen on FF.
On a page with no reverse ajax, it behaves normally.
If i revert back to dwr 2.0.1, the problem does not occurs...
Any ideas?
Thomas.
|
|
RE: Dwr 2.0.3, reverseAjaxEnabled and IE6
It sounds like both connections from IE to the server are
consumed. Check the connections with the free TcpView tool (from Microsoft,
formerly Sysinternals) to get to know more about what is
happening.
Best regards
Mike
Hi,
I've a strange behaviour with dwr 2.0.3 on page with reverse ajax enabled
on IE6.
and this parameter :
<init-param>
<param-name>maxWaitAfterWrite</param-name>
<param-value>500</param-value>
</init-param>
My App is a standart struts app.
If I get on a page with reverse ajax enabled, and then click any another
link, it takes about a minute to achieve the action.
This does not happen on FF.
On a page with no reverse ajax, it behaves normally.
If i revert back to dwr 2.0.1, the problem does not occurs...
Any ideas?
Thomas.
|
|
RE: Dwr 2.0.3, reverseAjaxEnabled and IE6
I had a quick look myself in TcpView and indeed it looks
like the good old zombie socket bug is triggered in IE when closing a page that
sits in a DWR poll. Could you check if you also have zombie sockets? Start
TcpView and look for sockets for iexplore.exe that are staying in the CLOSE_WAIT
state forever.
Best regards
Mike
It sounds like both connections from IE to the server are
consumed. Check the connections with the free TcpView tool (from Microsoft,
formerly Sysinternals) to get to know more about what is
happening.
Best regards
Mike
Hi,
I've a strange behaviour with dwr 2.0.3 on page with reverse ajax
enabled on IE6.
and this parameter :
<init-param>
<param-name>maxWaitAfterWrite</param-name>
<param-value>500</param-value>
</init-param>
My App is a standart struts app.
If I get on a page with reverse ajax enabled, and then click any
another link, it takes about a minute to achieve the action.
This does not happen on FF.
On a page with no reverse ajax, it behaves normally.
If i revert back to dwr 2.0.1, the problem does not occurs...
Any ideas?
Thomas.
|
|
Re: Dwr 2.0.3, reverseAjaxEnabled and IE6
Hi Mike,
I'll do that on monday(if I've some time, i've a lot of work and it works fine with 2.0.1), it's a business project.
Thanks.
Thomas.
On 3/15/08, Mike Wilson <mikewse@...> wrote:
I had a quick look myself in TcpView and indeed it looks like the good old zombie socket bug is triggered in IE when closing a page that sits in a DWR poll. Could you check if you also have zombie sockets? Start TcpView and look for sockets for iexplore.exe that are staying in the CLOSE_WAIT state forever.
Best regards
Mike
From: Mike Wilson [mailto:mikewse@...]
Sent: den 15 mars 2008 11:41
To: users@...
Subject: RE: [dwr-user] Dwr 2.0.3, reverseAjaxEnabled and IE6
It sounds like both connections from IE to the server are consumed. Check the connections with the free TcpView tool (from Microsoft, formerly Sysinternals) to get to know more about what is happening.
Best regards
Mike
From: Thomas Manson [mailto:dev.mansonthomas@...]
Sent: den 13 mars 2008 16:26
To: users@...
Subject: [dwr-user] Dwr 2.0.3, reverseAjaxEnabled and IE6
Hi,
I've a strange behaviour with dwr 2.0.3 on page with reverse ajax enabled on IE6.
and this parameter :
<init-param>
<param-name>maxWaitAfterWrite</param-name>
<param-value>500</param-value>
</init-param>
My App is a standart struts app.
If I get on a page with reverse ajax enabled, and then click any another link, it takes about a minute to achieve the action.
This does not happen on FF.
On a page with no reverse ajax, it behaves normally.
If i revert back to dwr 2.0.1, the problem does not occurs...
Any ideas?
Thomas.
|
|
RE: Dwr 2.0.3, reverseAjaxEnabled and IE6
Thomas, I have created this bug
report
for the bug I was seeing. I'll check in a fix the next few
days and it would be interesting to see if it solves your problem also. Is it
possible for you to run with the code from CVS?
Best regards
Mike
Hi Mike,
I'll do that on monday(if I've some time, i've a lot of work and it
works fine with 2.0.1), it's a business project.
Thanks.
Thomas.
On 3/15/08, Mike
Wilson <mikewse@...> wrote:
I had
a quick look myself in TcpView and indeed it looks like the good old zombie
socket bug is triggered in IE when closing a page that sits in a DWR poll.
Could you check if you also have zombie sockets? Start TcpView and look for
sockets for iexplore.exe that are staying in the CLOSE_WAIT state
forever.
Best
regards
Mike
From: Mike Wilson [mailto:mikewse@...]
Sent: den 15 mars 2008 11:41
To: users@...
Subject: RE:
[dwr-user] Dwr 2.0.3, reverseAjaxEnabled and
IE6
It
sounds like both connections from IE to the server are consumed. Check the
connections with the free TcpView tool (from Microsoft, formerly
Sysinternals) to get to know more about what is
happening.
Best
regards
Mike
From: Thomas Manson [mailto:dev.mansonthomas@...]
Sent: den 13
mars 2008 16:26
To: users@...
Subject: [dwr-user]
Dwr 2.0.3, reverseAjaxEnabled and IE6
Hi,
I've a strange behaviour with dwr 2.0.3 on page with reverse ajax
enabled on IE6.
and this parameter :
<init-param>
<param-name>maxWaitAfterWrite</param-name>
<param-value>500</param-value>
</init-param>
My App is a standart struts app.
If I get on a page with reverse ajax enabled, and then click any
another link, it takes about a minute to achieve the action.
This does not happen on FF.
On a page with no reverse ajax, it behaves normally.
If i revert back to dwr 2.0.1, the problem does not occurs...
Any ideas?
Thomas.
|
|
Re: Dwr 2.0.3, reverseAjaxEnabled and IE6
Hi,
On Mon, Mar 17, 2008 at 11:00 AM, Mike Wilson < mikewse@...> wrote:
>
>
> Thomas, I have created this bug report
>
> http://getahead.org/bugs/browse/DWR-235> for the bug I was seeing. I'll check in a fix the next few days and it would
> be interesting to see if it solves your problem also. Is it possible for you
> to run with the code from CVS?
It sounds like that's the issue I'm experiencing with (popup) windows
closed when XHR calls are being processed
( http://www.nabble.com/forum/ViewPost.jtp?post=15769147&framed=y)
although I didn't use any reverse AJAX and it was the reason for me
switching to IFrame RPC.
I just tried with the latest CVS (Branch_2_0 branch from java.net)
with no success: IE gets those CLOSE_WAIT connections forever after
closing the popup window.
Regards,
--
Fiouz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
--
Fiouz
|
|
RE: Dwr 2.0.3, reverseAjaxEnabled and IE6
> I just tried with the latest CVS (Branch_2_0 branch from java.net)
> with no success: IE gets those CLOSE_WAIT connections forever after
> closing the popup window.
That sounds reasonable as I haven't checked it in yet ;-)
I'm working on the fix and will report back in this discussion thread
(and JIRA) when it is available in CVS.
Best regards
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
|
|
Re: Dwr 2.0.3, reverseAjaxEnabled and IE6
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Mike,
I was a bit busy lately ;)
I've just made the test with TcpView, only One IE launched.
When connected, I've a UDP connection, and 2 TCP ESTABLISHED.
When I click the first time, the action is executed normally.
The second time it takes lot of time.
When I check TcpView, I don't see any connection in CLOSE_WAIT mode.
But I notice that the browser display the next page just after one of the two established connection is closed and replace by another connection. (the reverse ajax connection ?)
Thomas.
On 3/17/08, Mike Wilson <mikewse@...> wrote:
> I just tried with the latest CVS (Branch_2_0 branch from java.net)
> with no success: IE gets those CLOSE_WAIT connections forever after
> closing the popup window.
That sounds reasonable as I haven't checked it in yet ;-)
I'm working on the fix and will report back in this discussion thread
(and JIRA) when it is available in CVS.
Best regards
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
|
|
RE: Dwr 2.0.3, reverseAjaxEnabled and IE6
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Thomas,
There are variations to what happens under different
circumstances with this IE bug. Here is an attempt to summarize the bug
pattern:
- The client code sends an XHR request to the
server.
- The user leaves the page before the response
arrives.
- IE will wait for the response even though the page is
gone, occupying the connection.
- If the response is returned in chunked mode (always used
by polls) AND the owning window has been closed, then the socket will become a
zombie socket forever occupying the connection in CLOSE_WAIT state. Otherwise it
will be returned to the browser pool.
It sounds like you are staying in the same window and thus
would just experience the delay until the "old" reverse ajax connection is
released.
I have fixed the problem by aborting all ongoing XHR:s at
page unload, and I'll check in the fix as soon as SVN becomes
available.
Best regards
Mike
Hi Mike,
I was a bit busy lately ;)
I've just made the test with TcpView, only One IE launched.
When connected, I've a UDP connection, and 2 TCP ESTABLISHED.
When I click the first time, the action is executed normally.
The second time it takes lot of time.
When I check TcpView, I don't see any connection in CLOSE_WAIT
mode.
But I notice that the browser display the next page just after
one of the two established connection is closed and replace by another
connection. (the reverse ajax connection ?)
Thomas.
On 3/17/08, Mike
Wilson <mikewse@...>
wrote:
>
I just tried with the latest CVS (Branch_2_0 branch from java.net)
> with no success:
IE gets those CLOSE_WAIT connections forever after
> closing the popup
window.
That sounds reasonable as I haven't checked it in yet
;-)
I'm working on the fix and will report back in this discussion
thread
(and JIRA) when it is available in CVS.
Best
regards
Mike
---------------------------------------------------------------------
To
unsubscribe, e-mail: users-unsubscribe@...
For additional
commands, e-mail: users-help@...
|
|
Re: Dwr 2.0.3, reverseAjaxEnabled and IE6
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Ok Mike,
I'll test the 2.0.4 when it will be out !
Thanks,
Thomas.
On 3/27/08, Mike Wilson <mikewse@...> wrote:
Hi Thomas,
There are variations to what happens under different circumstances with this IE bug. Here is an attempt to summarize the bug pattern:
- The client code sends an XHR request to the server.
- The user leaves the page before the response arrives.
- IE will wait for the response even though the page is gone, occupying the connection.
- If the response is returned in chunked mode (always used by polls) AND the owning window has been closed, then the socket will become a zombie socket forever occupying the connection in CLOSE_WAIT state. Otherwise it will be returned to the browser pool.
It sounds like you are staying in the same window and thus would just experience the delay until the "old" reverse ajax connection is released.
I have fixed the problem by aborting all ongoing XHR:s at page unload, and I'll check in the fix as soon as SVN becomes available.
Best regards
Mike
From: Thomas Manson [mailto:dev.mansonthomas@...]
Sent: den 27 mars 2008 13:44
To: users@...
Subject: Re: [dwr-user] Dwr 2.0.3, reverseAjaxEnabled and IE6
Hi Mike,
I was a bit busy lately ;)
I've just made the test with TcpView, only One IE launched.
When connected, I've a UDP connection, and 2 TCP ESTABLISHED.
When I click the first time, the action is executed normally.
The second time it takes lot of time.
When I check TcpView, I don't see any connection in CLOSE_WAIT mode.
But I notice that the browser display the next page just after one of the two established connection is closed and replace by another connection. (the reverse ajax connection ?)
Thomas.
On 3/17/08, Mike Wilson <mikewse@...> wrote:
> I just tried with the latest CVS (Branch_2_0 branch from java.net)
> with no success: IE gets those CLOSE_WAIT connections forever after
> closing the popup window.
That sounds reasonable as I haven't checked it in yet ;-)
I'm working on the fix and will report back in this discussion thread
(and JIRA) when it is available in CVS.
Best regards
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
|
|
RE: Dwr 2.0.3, reverseAjaxEnabled and IE6
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Thomas,
I am now back from vacation and Joe checked in my code in
SVN while I was gone. If possible, it would be interesting to know if your issue
is fixed when running with latest DWR from Branch_2_0
in SVN?
Best regards
Mike
Ok Mike,
I'll test the 2.0.4 when it will be out !
Thanks,
Thomas.
On 3/27/08, Mike
Wilson <mikewse@...> wrote:
Hi
Thomas,
There
are variations to what happens under different circumstances with this IE
bug. Here is an attempt to summarize the bug pattern:
- The
client code sends an XHR request to the server.
- The
user leaves the page before the response arrives.
- IE
will wait for the response even though the page is gone, occupying the
connection.
- If
the response is returned in chunked mode (always used by polls) AND the
owning window has been closed, then the socket will become a zombie socket
forever occupying the connection in CLOSE_WAIT state. Otherwise it will be
returned to the browser pool.
It
sounds like you are staying in the same window and thus would just
experience the delay until the "old" reverse ajax connection is
released.
I have
fixed the problem by aborting all ongoing XHR:s at page unload, and I'll
check in the fix as soon as SVN becomes available.
Best
regards
Mike
From: Thomas Manson
[mailto:dev.mansonthomas@...]
Sent: den
27 mars 2008 13:44
To: users@...
Subject: Re: [dwr-user]
Dwr 2.0.3, reverseAjaxEnabled and IE6
Hi Mike,
I was a bit busy lately ;)
I've just made the test with TcpView, only One IE
launched.
When connected, I've a UDP connection, and 2 TCP
ESTABLISHED.
When I click the first time, the action is executed
normally.
The second time it takes lot of time.
When I check TcpView, I don't see any connection in CLOSE_WAIT
mode.
But I notice that the browser display the next page just
after one of the two established connection is closed and replace by
another connection. (the reverse ajax connection ?)
Thomas.
On 3/17/08, Mike
Wilson <mikewse@...> wrote:
>
I just tried with the latest CVS (Branch_2_0 branch from java.net)
> with no
success: IE gets those CLOSE_WAIT connections forever after
>
closing the popup window.
That sounds reasonable as I haven't
checked it in yet ;-)
I'm working on the fix and will report back in
this discussion thread
(and JIRA) when it is available in
CVS.
Best
regards
Mike
---------------------------------------------------------------------
To
unsubscribe, e-mail: users-unsubscribe@...
For additional
commands, e-mail: users-help@...
|
|
Re: Dwr 2.0.3, reverseAjaxEnabled and IE6
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Mike,
I'm checking out the head of Branch_2_0, but I'm not sure that I'll be able to easily build the jar. (I've no jdk 1.3...)
Could you build it for me and sent it via mail ?
Thomas
On 4/8/08, Mike Wilson <mikewse@...> wrote:
Hi Thomas,
I am now back from vacation and Joe checked in my code in SVN while I was gone. If possible, it would be interesting to know if your issue is fixed when running with latest DWR from Branch_2_0 in SVN?
Best regards
Mike
From: Thomas Manson [mailto:dev.mansonthomas@...]
Sent: den 27 mars 2008 14:38
To: users@...
Subject: Re: [dwr-user] Dwr 2.0.3, reverseAjaxEnabled and IE6
Ok Mike,
I'll test the 2.0.4 when it will be out !
Thanks,
Thomas.
On 3/27/08, Mike Wilson <mikewse@...> wrote:
Hi Thomas,
There are variations to what happens under different circumstances with this IE bug. Here is an attempt to summarize the bug pattern:
- The client code sends an XHR request to the server.
- The user leaves the page before the response arrives.
- IE will wait for the response even though the page is gone, occupying the connection.
- If the response is returned in chunked mode (always used by polls) AND the owning window has been closed, then the socket will become a zombie socket forever occupying the connection in CLOSE_WAIT state. Otherwise it will be returned to the browser pool.
It sounds like you are staying in the same window and thus would just experience the delay until the "old" reverse ajax connection is released.
I have fixed the problem by aborting all ongoing XHR:s at page unload, and I'll check in the fix as soon as SVN becomes available.
Best regards
Mike
From: Thomas Manson [mailto:dev.mansonthomas@...]
Sent: den 27 mars 2008 13:44
To: users@...
Subject: Re: [dwr-user] Dwr 2.0.3, reverseAjaxEnabled and IE6
Hi Mike,
I was a bit busy lately ;)
I've just made the test with TcpView, only One IE launched.
When connected, I've a UDP connection, and 2 TCP ESTABLISHED.
When I click the first time, the action is executed normally.
The second time it takes lot of time.
When I check TcpView, I don't see any connection in CLOSE_WAIT mode.
But I notice that the browser display the next page just after one of the two established connection is closed and replace by another connection. (the reverse ajax connection ?)
Thomas.
On 3/17/08, Mike Wilson <mikewse@...> wrote:
> I just tried with the latest CVS (Branch_2_0 branch from java.net)
> with no success: IE gets those CLOSE_WAIT connections forever after
> closing the popup window.
That sounds reasonable as I haven't checked it in yet ;-)
I'm working on the fix and will report back in this discussion thread
(and JIRA) when it is available in CVS.
Best regards
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
|
|
RE: Dwr 2.0.3, reverseAjaxEnabled and IE6
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Oh, you can build it with higher version JDKs as
well.
Or, if in Eclipse just let Eclipse compile the java
directory and specify the DWR project as a J2EE module dependency. Great way to
easily try out different versions without having to mess with jar
files.
Best regards
Mike
Hi Mike,
I'm checking out the head of Branch_2_0, but I'm not sure that
I'll be able to easily build the jar. (I've no jdk 1.3...)
Could you build it for me and sent it via mail ?
Thomas
On 4/8/08, Mike
Wilson <mikewse@...> wrote:
Hi
Thomas,
I am
now back from vacation and Joe checked in my code in SVN while I was gone.
If possible, it would be interesting to know if your issue is fixed
when running with latest DWR from Branch_2_0
in SVN?
Best
regards
Mike
|
