“No data received from server” from Explorer and Firefox

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.

What version of Glassfish are you using?  

# 1:

This was introduced by - http://directwebremoting.org/jira/browse/DWR-458.  Please create a new JIRA ticket for this and we will fix it.  We can't simply comment out the code as you suggest as this class is also used for Jetty continuations and the isSuspended check is required.

#2
Streaming is not supported by IE.

"If there’s not activity in our navigators (even Firefox, even IE) the reverse ajax is not reloaded and there’s a “No data received from server” error from server. The strange thing is that this happens when we have the logs of our application established to ERROR. If the DEBUG level is enabled our system works (apparently) rightly and reverse ajax is fired each 60 seconds."

This explanation doesn't make a whole lot of sense to me.  I will try to investigate this when I have some time.

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.

I noticed that the line numbers in the stacktrace don't really match up with RC2, so now I am wondering what else you modified.  Do you have to use Grizzly?  Can you move back to an unhacked version of DWR and try using Jetty Continuations?  This is possible with Glassfish, you just need to use the Continuation Filter:

Instructions here:
http://www.butterdev.com/dwr/2010/01/dwr-3-x-and-jetty-continuations-on-jetty-6-x/

You will also need to remove the Grizzly libraries from Glassfish.  

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.

I think the jetty stuff is a lot more stable/active.  The Grizzly Continuation I see is from 2008.  Anyway, I just deployed our sample application (dwr.war) in Glassfish 2.1 and our reverse ajax demos seem to be working fine.  Have you tried deploying our sample app?

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.

If you look inside the Grizzly jars you are using you will see that the dates on the class files are from 2008.  I strongly recommend that you try things out with Jetty Continuations.  

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.

Thanks for the detailed analysis.  Unfortunately it does not explain why our demo application works.  I made a few small changes to the Grizzly stuff (fixed null pointer in Continuation) and launched our demo with the Grizzly jars you are using.  I verified that the Grizzly Continuation was being used by remote debugging and our demo seemed to be working fine.  

My second problem is the code you changed doesn't just affect Grizzly (Jetty Continuations, etc.) and we have never had a similar problem reported.

Do you think it is possible to send us a deployable application that demonstrates the problem?  If not can you provide us more details on your configuration and more importantly when you are seeing this problem (all the time, at certain times?).

As far as the Jetty stuff - I fixed the link.  All you need is the continuation library and to follow the directions in the post.

Here is what I think is happening:

GrizzlyContinuationSleeper.wakeUp

       case SLEEPING:
          ....
                    // Flush bytes (if any) first before resuming as
                    // Grizzly Comet isn't allowing writes once the
                    // continuation is resumed.
                    onAwakening.run();
                    continuation.resume();
                }
          ...

From the comments Grizzly does not allow writes once the continuation has been resumed.  However, the call to run will return immediately so the continuation is being resumed before everything has been flushed to the browser. 

On Wed, Sep 7, 2011 at 5:41 AM, [hidden email] <[hidden email]> wrote:

Thanks for the detailed analysis.  Unfortunately it does not explain why our
demo application works.  I made a few small changes to the Grizzly stuff
(fixed null pointer in Continuation) and launched our demo with the Grizzly
jars you are using.  I verified that the Grizzly Continuation was being used
by remote debugging and our demo seemed to be working fine.

My second problem is the code you changed doesn't just affect Grizzly (Jetty
Continuations, etc.) and we have never had a similar problem reported.

Do you think it is possible to send us a deployable application that
demonstrates the problem?  If not can you provide us more details on your
configuration and more importantly when you are seeing this problem (all the
time, at certain times?).

As far as the Jetty stuff - I fixed the link.  All you need is the
continuation library and to follow the directions in the post.


--
View this message in context: http://dwr.2114559.n2.nabble.com/No-data-received-from-server-from-Explorer-and-Firefox-tp6761146p6767466.html

Sent from the DWR - Users mailing list archive at Nabble.com.

Maria, please see:
http://directwebremoting.org/jira/browse/DWR-538

What I would like you to do is watch this issue and then try out a new jar (removing all of your fixes) when it becomes available.  Can you do that?

On Wed, Sep 7, 2011 at 6:52 AM, David Marginian <[hidden email]> wrote:

Here is what I think is happening:

GrizzlyContinuationSleeper.wakeUp

       case SLEEPING:
          ....
                    // Flush bytes (if any) first before resuming as
                    // Grizzly Comet isn't allowing writes once the
                    // continuation is resumed.
                    onAwakening.run();
                    continuation.resume();
                }
          ...

From the comments Grizzly does not allow writes once the continuation has been resumed.  However, the call to run will return immediately so the continuation is being resumed before everything has been flushed to the browser. 

On Wed, Sep 7, 2011 at 5:41 AM, [hidden email] <[hidden email]> wrote:

Thanks for the detailed analysis.  Unfortunately it does not explain why our
demo application works.  I made a few small changes to the Grizzly stuff
(fixed null pointer in Continuation) and launched our demo with the Grizzly
jars you are using.  I verified that the Grizzly Continuation was being used
by remote debugging and our demo seemed to be working fine.

My second problem is the code you changed doesn't just affect Grizzly (Jetty
Continuations, etc.) and we have never had a similar problem reported.

Do you think it is possible to send us a deployable application that
demonstrates the problem?  If not can you provide us more details on your
configuration and more importantly when you are seeing this problem (all the
time, at certain times?).

As far as the Jetty stuff - I fixed the link.  All you need is the
continuation library and to follow the directions in the post.


--
View this message in context: http://dwr.2114559.n2.nabble.com/No-data-received-from-server-from-Explorer-and-Firefox-tp6761146p6767466.html

Sent from the DWR - Users mailing list archive at Nabble.com.

Also, regarding your "fix", it is not a reliable/proper fix.  By moving the cancelling of the alarms to the end of onAwakening.run() all you are doing is allowing the conduit to be closed sooner and therefore allowing the flush to occur sooner. You cannot rely on this.  Just because you are no longer seeing the issue with this "fix" in place does not mean the issue can no longer occur (you are simply getting lucky with timing).

On Wed, Sep 7, 2011 at 7:04 AM, David Marginian <[hidden email]> wrote:

Maria, please see:
http://directwebremoting.org/jira/browse/DWR-538

What I would like you to do is watch this issue and then try out a new jar (removing all of your fixes) when it becomes available.  Can you do that?

On Wed, Sep 7, 2011 at 6:52 AM, David Marginian <[hidden email]> wrote:

Here is what I think is happening:

GrizzlyContinuationSleeper.wakeUp

       case SLEEPING:
          ....
                    // Flush bytes (if any) first before resuming as
                    // Grizzly Comet isn't allowing writes once the
                    // continuation is resumed.
                    onAwakening.run();
                    continuation.resume();
                }
          ...

From the comments Grizzly does not allow writes once the continuation has been resumed.  However, the call to run will return immediately so the continuation is being resumed before everything has been flushed to the browser. 

On Wed, Sep 7, 2011 at 5:41 AM, [hidden email] <[hidden email]> wrote:

Thanks for the detailed analysis.  Unfortunately it does not explain why our
demo application works.  I made a few small changes to the Grizzly stuff
(fixed null pointer in Continuation) and launched our demo with the Grizzly
jars you are using.  I verified that the Grizzly Continuation was being used
by remote debugging and our demo seemed to be working fine.

My second problem is the code you changed doesn't just affect Grizzly (Jetty
Continuations, etc.) and we have never had a similar problem reported.

Do you think it is possible to send us a deployable application that
demonstrates the problem?  If not can you provide us more details on your
configuration and more importantly when you are seeing this problem (all the
time, at certain times?).

As far as the Jetty stuff - I fixed the link.  All you need is the
continuation library and to follow the directions in the post.


--
View this message in context: http://dwr.2114559.n2.nabble.com/No-data-received-from-server-from-Explorer-and-Firefox-tp6761146p6767466.html

Sent from the DWR - Users mailing list archive at Nabble.com.

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.

We did not originally author the Grizzly Continuation.  One of the original authors of Grizzly did.  There is a very specific reason why the resume is called after onAwakening.run which is explained in the comments and my previous posts.  

I do not agree with your assessment at this point.  If you read my last few posts and the JIRA issue I created I think I have explained the issue.  I think the fixes you have made are not correct/reliable and should not be used.  

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.

Maria,
   I made some changes here that I believe will fix the problem in the correct way.  Please try the jar on Bamboo which includes all of the changes and let me know if it works/doesn't work - http://directwebremoting.org/bamboo/browse/DWRTRUNK-ALL-345/artifact.  Do not make any changes to this jar, use it as is. 

On Wed, Sep 7, 2011 at 7:44 AM, [hidden email] <[hidden email]> wrote:

We did not originally author the Grizzly Continuation.  One of the original
authors of Grizzly did.  There is a very specific reason why the resume is
called after onAwakening.run which is explained in the comments and my
previous posts.

I do not agree with your assessment at this point.  If you read my last few
posts and the JIRA issue I created I think I have explained the issue.  I
think the fixes you have made are not correct/reliable and should not be
used.

--
View this message in context: http://dwr.2114559.n2.nabble.com/No-data-received-from-server-from-Explorer-and-Firefox-tp6761146p6767845.html

Sent from the DWR - Users mailing list archive at Nabble.com.

Maria,
   I made some changes here that I believe will fix the problem in the correct way.  Please try the jar on Bamboo which includes all of the changes and let me know if it works/doesn't work - http://directwebremoting.org/bamboo/browse/DWRTRUNK-ALL-345/artifact.  Do not make any changes to this jar, use it as is.  

[MariaLopez]

CONTENTS DELETED

The author has deleted this message.