ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Hello,

we are used icefaces 1.5.3 and everyting works fine, but after upgrading to 1.6 connections with server is lost, when user is idle for 20 - 30 s.

Configuration: Spring 2 + Icefaces 1.6 + Tomcat 5.5

Thanks for any ideas.

Hi,

did you set up the connection settings in your web.xml as described in the
develper's guide?

You can find some useful hints on pages 41+42 - Connection Management.

Hope that helps,
Michael

I just added parameter for "standard request scope".

In my opinion default values must be quite good for development.

I'm wrong?

We are facing the same problem on JBoss 4.0.5 + IceFaces 1.6 (MyFaces). The connection gets lost, but not on all computers, just on those that are "farther". Farther means possibly a different domain ... or belonging to different security constraints. So on my development machine, or on another one which is directly connected to me, everything is ok, but on some other machines, the connection gets lost very fast.
I have these settings in web.xml

<context-param>
<param-name>com.icesoft.faces.heartbeatInterval</param-name>
<param-value>30000</param-value>
</context-param>

<context-param>
<param-name>com.icesoft.faces.heartbeatTimeout</param-name>
<param-value>10000</param-value>
</context-param>

<context-param>
<param-name>com.icesoft.faces.heartbeatRetries</param-name>
<param-value>5</param-value>
</context-param>

<context-param>
<param-name>com.icesoft.faces.connectionTimeout</param-name>
<param-value>1800000</param-value>
</context-param>

<session-config>
<session-timeout>30</session-timeout>
</session-config>

It's really a shame that it behaves like that, for the user it's a serious nuisance to keep pressing F5, especially if they have just filled a big form.

Hi all,

I have the same problem with JBoss 4.0.5 + IceFaces 1.6

I have tried to change parameters into web.xml file but I didn't find any solution.

@edykory:

Are the machines that you're seeing the lost connections on a different network that may be dropping persistent connections? Your settings look fine.

Philip

Hi Philip ... long time no see :) .
We're now in the process of deploying the application to the client .. a bank ... I will talk these days to their IT guys, maybe I'll get some insights about that.
But you can imagine the surprise I had moving from development (where everything went OK) to production (well testing, but for them it's the same), where connection started getting lost :).
Thanx a lot for the idea. If this works ... I'll send you a card from Romania.
Cheers !

When we was using icefaces 1.5.3 everything was fine and client start loosing connections when we migrated to Icefaces 1.6.

Another interesting thing is javascript errors shown by Firebug. In Icefaces 1.5.3 there was't js errors. I'l give more detailed info soon.

I've the same problem since upgrading from Icefaces 1.5.3 to 1.6. I'm using the default values (e.g. I didn't specify them in web.xml) with Tomcat 5.5.20 and Sun JSF-RI. There's sure no network problem, since this also happens on localhost.

A workaround is to use synchronous updates, but then file upload doesn't work.

Hi there !
We are now in the testing time for our application at the client's site ... and we're also having the same problem with the connection getting lost. Now, I talked to their IT guys ... and they're not dropping any persistent connection or stuff like that ... everything is configured as default.
Then I started analyzing the app with the FireBug extension on FireFox (very smart thing). What I noticed is that the "pong" sometimes gets lost ... (and if you understand the heart beating mechanism ... this is not a disaster, it's just the beginning). Now what I also noticed is that most often than not it recovers ... it means that the 3rd, 4th ping returns, even after 2 failures.
I don't know if the problem comes from the JBoss we're using (it's the 4.0.5 default configuration), the network infrastructure or the IceFaces heart beating, but what my suggestion is to decrease the heart beating interval (like to 20.000ms), increase the heart beating timeout (to about 10.000ms) and the heart beating attempts (to maybe 10 or even 20).
This will make the application run longer and will give it more chances to recover from this kind of connection problems.
Cheers and good luck !

Like edykory, we tried to look at firebug console. There was same problem with loosed ping-pong request therefore we decided to change our configuration settings by increasing heartbeat attempts ant connectiontimeout parameter.

We solved our problem by changing configuration, but I think that "loosing ping-pong requests" need deeper investigation.

Thanx for help.

Please correct me if I'm wrong, but the connectionTimout parameter is not related to heart beating mechanism, but rather to the time the connection status component waits for a request to return before declaring the connection lost. What I mean is that it helps to increase it if you have operations which take a longer time on the server side (like very long forms, or some database connections which take long time to setup before getting the response, etc). So it affects the normal synchronous requests, not the heart beating behavior (which is asynchronous).

We are about to go in production with ICEfaces 1.6.

What would be the reason for the connection to drop once it is deployed on the production server?

1. Is it dropping because of network delays caused by the fact that the production server is far enough from the client machine accessing the application?

2. Is it multiple clients that are accessing the application simultaneously? We had a similar problem in the past, where we reached the maximum allowed connections causing some requests randomly to be dropped?

Edykory, did you check the access logs in tomcat/jboss to see if the dropped requests are logged?

Anyone has other ideas of why this problem might happen?

Thanks.

edykory wrote:

Please correct me if I'm wrong, but the connectionTimout parameter is not related to heart beating mechanism, but rather to the time the connection status component waits for a request to return before declaring the connection lost. What I mean is that it helps to increase it if you have operations which take a longer time on the server side (like very long forms, or some database connections which take long time to setup before getting the response, etc). So it affects the normal synchronous requests, not the heart beating behavior (which is asynchronous).

That is correct.