How to Stop the default polling /gwteventservice POST request

[GoogleCodeExporter]

I am using gwteventservice1.2 version from the trunk.

I have configured the eventservice.properties in the classpath with the below 
values

eventservice.time.waiting.min=0
eventservice.time.waiting.max=30
eventservice.time.timeout=90000

I do see a default /gwteventservice POST request re-occuring every 30sec (which 
looks like a polling POST request).

I am able to fire events from the users on the server side and it works perfect.

But is there any way to stop the default /gwteventservice POST request which is 
occuring every 30 sec of interval.

If i try to give a long value like (480000 - 8 minutes) for the max wait then I 
do see the polling POST request which occurs earlier every 30 sec get stopped 
but the events fired from the server side are not listened on the client side 
and the gwt event service does not work as expected.

Any help would be appreciated.

Thanks.

Original issue reported on code.google.com by leogem0...@gmail.com on 23 Nov 2011 at 12:06

[GoogleCodeExporter]

I think the problem is that you may haven't changed the timeout time after 
increasing the max. waiting time. When the timeout time is reached before the 
max. waiting time is exceed, GWTEventService deregisters the client/user and 
sends an UnlistenEvent which will also be logged. I think this is happened in 
your case.

The connection cycle is executed to avoid any (client/browser/connection) 
timeout recognitions and can not become completely disabled. You have of course 
the option to set it to a very high value, like your 8 minutes.

This configuration should re-schedule the connection only every 8 minutes.

eventservice.time.waiting.min=0
eventservice.time.waiting.max=480000
eventservice.time.timeout=999999

Original comment by sven.strohschein@googlemail.com on 23 Nov 2011 at 10:12

[GoogleCodeExporter]

Hi Sven,

I have given the above configuration parameters as responded by you where the 
time out time is more then the max time but the GWTEventService does not work. 
It looks like the events pushed from the server side are not listened by the 
listeners on the client side if the max time is even more than 5 minutes.

It looks like there is a bug in GWTEventService and currently there is no way 
to increase the max wait time.

In our case the default POST request which is occuring every 30 sec as per our 
configuration is causing an issue since now our servers are seeing so many hits 
with this default POST/polling request.

Is there any way we can fix this bug?

Thanks.

Original comment by leogem0...@gmail.com on 5 Dec 2011 at 8:55

[GoogleCodeExporter]

To avoid freqent connection checking request, I set the following event 
properties , with this frequency of connection checking calls is less but the 
server push is not consistent and it stopped working when browser session went 
idle for few mins,,not sure what is the relation with max wait time propertu, 
it works fine when wait time are in secs ( 1 or 2 sec), could you please 
suggest solution to keep server push active when max wait time value is 
increased, in all cases timeout was set to very large value

eventservice.time.waiting.max=300000
eventservice.time.waiting.min=0
eventservice.time.timeout=999999
eventservice.reconnect.attempt.count=2
eventservice.connection.id.generator=de.novanic.eventservice.service.connection.
id.SessionExtendedConnectionIdGenerator

Original comment by yasmeen....@gmail.com on 5 Dec 2011 at 8:59

[GoogleCodeExporter]

Hi,

I have tested my posted configuration with the DemoConversationApp and Apache 
Tomcat 6.0.33. That worked fine. Which web-servers do you use? Could you please 
check if a session or connection timeout is configured within the web-server 
configuration?

Original comment by sven.strohschein@googlemail.com on 8 Dec 2011 at 7:23

[GoogleCodeExporter]

Hi,

What is the connection timeout configured when you tested on Tomcat 6.0.33?

Did you configured the Tomcat for Asynchronous HTTP Request Processing?

We are using JBoss 4.2.3 application server which has integration with Tomact 6 
as the web server.

We do not want to use the Asynchronous HTTP Request Processing since it will 
impact the performance of our application server and waste resources.

We would like the solution where a request is only posted to the client when 
the Event is triggered.

If this thing did not work then we have to look into the solutions like 
Asynchronous messaging sending messages to a Java Applet on the client side 
which will act as a listener to consume the messages. 

Thanks.

Original comment by leogem0...@gmail.com on 10 Dec 2011 at 1:23

[GoogleCodeExporter]

Below is the connection time out settings.

connectionTimeout="20000"

Thanks.

Original comment by leogem0...@gmail.com on 10 Dec 2011 at 2:57

[GoogleCodeExporter]

I gave a large time out value on our web server configuration and its the same 
issue.

The GWTEventService does not push messages if your browser session is opened 
for more than 5 minutes with the large time out value.

You can even reproduce the same on your DemoConverstionApp, just keep your 
browser session remain open for longer time (more than 5 min) and try to push 
the data from the server side. The event service stops listening on the client 
side for the user session.

Thanks.

Original comment by leogem0...@gmail.com on 10 Dec 2011 at 3:52

[GoogleCodeExporter]

Hi,

I think the connectionTimeout of your JBoss server is too short. It has to be 
set higher than "eventservice.time.waiting.max" otherwise the JBoss server will 
cancel the connection. With your configuration, GWTEventService will wait 8 
minutes for occurring events, but JBoss cancels the connection after 20 
seconds...
You could try to set connectionTimeout of the JBoss server to something like 
"500000" or to set down "eventservice.time.waiting.max" to a value which is 
smaller than your configured connectionTimeout.

Original comment by sven.strohschein@googlemail.com on 18 Dec 2011 at 6:26

[GoogleCodeExporter]

@leogem0280: Does this problem still occur? Have you checked my last answer?

Original comment by sven.strohschein@googlemail.com on 16 Jul 2012 at 5:44

[GoogleCodeExporter]

Original comment by sven.strohschein@googlemail.com on 16 Jul 2012 at 5:47

• Added labels: Waitingforresponse

[GoogleCodeExporter]

Issue set to invalid because it seems to be a configuration problem and the 
last request wasn't answered since three weeks. When this supposition will be 
detected as false, the issue may be re-opened.

Original comment by sven.strohschein@googlemail.com on 7 Aug 2012 at 2:26

• Changed state: Invalid