Issue Details (XML | Word | Printable)

Key: DOL-158
Type: Feature Request Feature Request
Status: Open Open
Priority: Minor Minor
Assignee: Dierk Koenig
Reporter: Michael Heinrichs
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Dolphin

PushListener needs to slow down, if it fails

Created: 05/Jan/16 04:39 PM   Updated: 06/Jan/16 09:15 AM
Component/s: Communication-Level
Affects Version/s: 0.11
Fix Version/s: 1.0
Security Level: public

Time Tracking:
Not Specified


 Description  « Hide
At present, if sending the push-listening command fails, OpenDolphin immediately sends a new PushListening command. As nothing was really done to resolve the issue, it is very likely to fail again. In our case this results in dozens of unsuccessful attempts per second which renders the logs unusable.

It would be better, if this functionality slows down after a number of failed attempts automatically. Another solution would be to leave this to the application, which requires some hooks to become notified of issues and some mechanisms to control how often the pushListening command is sent.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Dierk Koenig added a comment - 05/Jan/16 06:00 PM
If the default way for push listening needs to be customized for a given application, the programmer can fully roll his own logic.
The PushView example shows an approach that allows putting in any kind of custom logic:
https://github.com/canoo/open-dolphin/blob/3fc94b4bae95eaa2333e3fc6b8c4317d4a036d5c/subprojects/demo-javafx/client/src/main/groovy/org/opendolphin/demo/PushView.groovy#L42-L43

Of course, one could also provide a feature on the standard start-/stopPushListening that allows some kind of "unavailable strategy" to be configured.
Other options would be to set specialized ResponseHandler in the HttpClientConnector or setting a suitable onException logic in the ClientConnector.


Andres Almiray added a comment - 06/Jan/16 09:15 AM
This issue is somehow related to the ongoing discussion of proper resource cleanup currently missing in version 1.0-RC1