Closed GoogleCodeExporter closed 8 years ago
A workaround should be possible with the timeout / unlisten listeners
introduced with version 1.1. When an unlisten event occurs, the client side
timeout / unlisten listener could register the client again. That will be
implemented automatically with version 1.2.
Marked as an enhancement instead of a defect.
Original comment by sven.strohschein@googlemail.com
on 22 Jun 2010 at 4:54
How to do it?
How to "register client again"? Should I add all RemoteEventListener again?
Original comment by bartosz....@gmail.com
on 10 Aug 2010 at 1:37
Yes, all RemoteEventListeners have to get registered again, when an
UnlistenEvent occurs (listen for it with an UnlistenEventListener). That is a
manual implementation / workaround...
All other features of GWTEventService 1.2 are now implemented and the
realization of this feature will start in the next days/weeks. If you are
planning to implement it by yourself you could also try to implement it
directly in GWTEventService 1.2 / trunk to support the team (if you feel like).
Just mail me.
Original comment by sven.strohschein@googlemail.com
on 10 Aug 2010 at 8:00
Firefox has "feature". It kills requests when user press Esc.
I made simple patch. After error it tries to reconnect three times.
### Eclipse Workspace Patch 1.0
#P gwteventservice
Index:
src/main/java/de/novanic/eventservice/client/event/DefaultRemoteEventConnector.j
ava
===================================================================
---
src/main/java/de/novanic/eventservice/client/event/DefaultRemoteEventConnector.j
ava (revision 388)
+++
src/main/java/de/novanic/eventservice/client/event/DefaultRemoteEventConnector.j
ava (working copy)
@@ -19,7 +19,9 @@
*/
package de.novanic.eventservice.client.event;
+import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.rpc.AsyncCallback;
+import com.google.gwt.user.client.rpc.StatusCodeException;
import java.util.List;
@@ -50,7 +52,8 @@
private boolean isActive;
private ConnectionStrategyClientConnector myConnectionStrategyClientConnector;
private UnlistenEvent myUnlistenEvent;
-
+ private int errorsCount = 0;
+
/**
* Initializes the listen method implementation with a {@link de.novanic.eventservice.client.connection.strategy.connector.ConnectionStrategyClientConnector}.
* That is required to specify the listen / connection strategy. The connection strategy can't be changed, when the listening has already started / an listener was added.
@@ -181,10 +184,15 @@
myEventNotification = anEventNotification;
}
- public void onFailure(Throwable aThrowable) {
- LOG.error("Error on processing event!", aThrowable);
- fireUnlistenEvent(myEventNotification);
- }
+ public void onFailure(Throwable aThrowable) {
+ LOG.error("Error on processing event!", aThrowable);
+ if (errorsCount++ > 2) {
+ fireUnlistenEvent(myEventNotification);
+ } else {
+ LOG.log("Reconnecting after error");
+ callListen();
+ }
+ }
/**
* Calls listen on the server side and put itself as the callback to produces the listen cycle as long as the
@@ -193,6 +201,7 @@
* @see de.novanic.eventservice.client.event.GWTRemoteEventConnector.ListenEventCallback#callListen()
*/
public void onSuccess(List<DomainEvent> anEvents) {
+ errorsCount = 0;
if(anEvents != null) {
for(DomainEvent theEvent: anEvents) {
myEventNotification.onNotify(theEvent);
Original comment by bartosz....@gmail.com
on 11 Aug 2010 at 11:51
Wow, that was fast and it looks really good! I have tested it today and it does
also solve the ESC feature/bug of Firefox. Great!
I will test it in the next days more intensive with real connection issues.
Maybe we need a timer which starts the reconnect attemps with in interval
because the reconnect calls could be executed too fast.
Thank you for the patch/solution!
Original comment by sven.strohschein@googlemail.com
on 11 Aug 2010 at 10:01
I have committed your solution of the automatic reconnect feature. Thanks for
it Bartosz M.! It's working fine.
The second step is to provide a reconnect attempt interval and to make the
number/count of reconnect attempts configurable. One missing step is also the
missing error handling of the streaming client connector. Therefore the
solution and unlisten events aren't working with streaming at the moment (1.2).
After that is solved this issue/ticket can be closed.
Original comment by sven.strohschein@googlemail.com
on 19 Aug 2010 at 8:22
Is there already a way to configure the number of reconnect attempts? Even
though the reconnect works well, I will have to disable it in my concrete case.
In the period between connection loss and reconnect, there might occur an event
that is then not received by the client. To recover the lost event, I will have
to be aware of a disconnect. The unlisten event listener that I used in v1.1 is
only called after the third try - I would either like to get the number of
attempts that already occured - or to the attempts to 0.
Thanks for all the work you dedicated to this project!
Original comment by eisw...@unterderbruecke.de
on 27 Mar 2011 at 8:34
[deleted comment]
There is now a way to configure the number of reconnects and it has to be
configured to activate the automatic reconnect functionality, because the
default value is zero (for compatibility reasons). It can be configured with
the configuration parameter "reconnect.attempt.count" /
"eventservice.reconnect.attempt.count".
Revision 422 (trunk version of GWTEventService): The number of reconnect
attempts can now be configured with the configuration parameter
"reconnect.attempt.count" / "eventservice.reconnect.attempt.count". The default
value is zero for compatibility reasons (upgrading from an earlier version will
not cause that reconnects are activated automatically), but the recommend value
is 2 (configured in the eventservice.properties which could be used as a
template / recommend configuration for new projects). ; RemoteEventConnector
interface changed to provide the configuration instead of a single client
connector.
Original comment by sven.strohschein@googlemail.com
on 12 Jun 2011 at 10:00
Fixed in version 1.2 RC1
Original comment by sven.strohschein@googlemail.com
on 28 Oct 2011 at 7:21
Original issue reported on code.google.com by
jea...@gmail.com
on 8 Jun 2010 at 8:53