Firefox Offline Mode Reconnect Issues

[Flamenco]

Using firefox-19-mac:

I have a non-upgraded stream or long-poll connection to either a tomcat or jetty server. When I select in the file menu, the polling request is disconnected, and no more attempts to reconnect happen, even after deselecting the feature.

However, if I pull the Ethernet plug, or disable the network interface, and then reconnect, my comet connection continues to work.

[Flamenco]

The status from the request is 'aborted' and perhaps this causes a maximum retry to occur. One would expect the client to back-off but continue to retry if the user disables connectivity from the browser. Maybe there is a way to distinguish between disconnects from network, server, and user initiated.

[laeubi]

I also noticed this, but not sure if it is intentional. Sadly the error
handling on clientside of atmosphere is very poor and limited. Once the
client get disconnected (e.g. server or connection gets down) there is
no good way to recover from this state atm.

[Flamenco]

How about not incrementing the retry if the response code is 'aborted'?

[jfarcand]

@iaeubi: Can you elaborate? First time someone complains about that. @Flamenco Can you elaborate? You means you reload the page or you close the connection manually?

[laeubi]

Can you elaborate?
Sure

You means you reload the page or you close the connection manually?
The problem arises, when the browser lost the connection (consider a
mobile user with temporary no internet access) or when the server goes
down (e.g. restart) then the "max-retry-limit" is hit within short time
and then no new attempts are made to recover from this state. IMO ther
should be something like try to recover "max-retry-times", then wait
some "recover-after-failure" timeout (eg 5 seconds) and then start over
again.

I tried to do this from clientcode but the callbacks are not that
usefull, e.g. the error code is always 500, the client has no idea how
often an onError is triggered, sometimes between an onReconnect is
triggered even if the server is down or the script tries to downgrade on
404 errors...

To solve this, atmosphere should use a more robust and more semantic
error handling that takes server return codes into account, a 404 error
will likeley not be solved by downgrading from streaming to long-polling
etc...
To be usefull on clientside the semantics should be someting like this:

• onConnect: Is triggered only once when the client invokes connect or a
  manuall reconnect
• onReconnect: Is only triggerd each time the connection was successfull
  recovered, and not e.g. when a long-polling or streaming is closed/reopened
• onDowngrade: Is triggered when the lib decides to downgrade, a user
  might provide a fall-back method then...
• onConnectionLost: fired each time a connection was previously made but
  "max-retry-times" has expired and the "recover-after-failure" period had
  started
• onError: only triggered once when the socket ultimatevly failed, e.g.
  no more fall-back methods are avaiable, and no more attempts will be
  made to recover from this state (so client code knows that now it is
  time to a) inform the user or b) recreate the socket

(I just named the events semantically, so just keep them as examples...)

Hope this helps in understand the issue :-)

[jfarcand]

(1) You can configure a timeout between reconnection => that does exactly what you want when you say:

then wait some "recover-after-failure" timeout (eg 5 seconds) and then start over again.

Just set a timeout and a bigger value that 5 for reconnecting, and you will have exactly what you want.

a 404 error will likeley not be solved by downgrading from streaming to long-polling etc...

I disagree. A server or and application can decide to return a 404 on websocket for whatever reason. What can be improved in atmosphere is to have a property that prevent downgrade and instead fail as it is. But you can already do that by closing the request inside a onTransportFailure

I like the onConnectionLost, that could be implemented on top of the onError current behavior. Please file another issue so I will work on it for 1.1. Thanks!

[laeubi]

You can configure a timeout between reconnection => that does exactly
what you want
Not really... that are just two cases e.g. I want to reconnect fast
until some kind of threshold is reached and then lessen the burdon on
the client to retry with a larger intervall.

I disagree. A server or and application can decide to return a 404 on
websocket for whatever reason
The application might decide to return even a '418' response, right, but
thats not very semantic, there is a reason for having different return
codes for different purposes.

What can be improved in atmosphere is to have a property that prevent
downgrade
Its just a little confusing that error are not distinguished from downgrades

e.g. the onError is invoked multiple times and so the client can't just
reopen the socket becaue that will end up in multiple socket creations.