I configure heartbeat in xml as 2 sec and now I’m having a performance issue since it always tell me a communication error… anyone have an idea why is that happening? Thanks.
I am not sure why you are getting communication error may be due to 404 response from the client.
Why is that you need an hearbeat interval configured for 2 seconds? Make it 1 min or atleast 30 seconds not so low as single digit.
Can you please give us a stripped down version of your source?
Thanks,
Krishna
Please run your application with the ?debug parameter appended to the URL and see what the log says when you get the error. Also check the server-side log for any errors reported.
Hello Johannes,
Just a question, What would happen if the response for heartbeat interval returns only after another heartbeat request is sent to the server. As the user has given interval time as 2 seconds may be due to network or load or session lock the request may get stuck on the server and then comes another request which gets struck on the server either. There is a valid chance of getting Communication Error right?
Pls correct me If I am wrong.
Thanks,
Krishna.
Hi Krishna, a good question. The exact scenario you describe shouldn’t be possible, though, because the next heartbeat is only scheduled once the response to the current one arrives to the client. However, in a high-contention situation frequent heartbeats might interfere with other requests - but that should still not cause a communication error, just slowness.
Hello Johannes,
Thanks for the clarification. I remember in one of the app I have written, the heartbeat got struck on the server due to Session Locking which took more than 3 minutes to get the lock released, this actually caused communication error on the client side due to heartbeat interval request returned back with 404 status as respone
-Krishna
Hi Johannes,
I did what you tell me… I run it using debug mode… from what I saw, The heartbeat dont response once I load a very big transaction… like querying from database, especially once the transaction took 5-10 sec. Anyway, I set the heartbeat to 10 sec… and i dont get error anymore.
P,S. once I received communication error my session doesn’t remove so nothing to worry about… it just the annoying communication error…
-Lance
Oh, right. You’re keeping the session locked for the duration of your long transaction, which means the heartbeats can’t get through (as they also need the session lock to update the internal bookkeeping)… still, they
shouldn’t
cause a visible communication error. Except that hmm, if the transaction is long enough, the sever-side logic may actually get confused, see that there haven’t been any heartbeats for a while (as the request has been waiting for the lock) and decide the UI should be closed. I think there’s a ticket about that scenario somewhere…
Thank you for the prompt reply… hope this issue will be fixed…
Thanks again.
Hi Johannes,
I’m really sorry but I’m having problem with this right now. I have an application that has a very big data, more than a thousand, a million after 3 months. So there will be a big chance that my query will took longer than before, Yes, I did my best to make the query faster, with the help of our database analyst. What I need is a short heartbeat, 10 secs maybe, because I’m using it to check if the user is still active. But everytime I have a transaction that took almost 40 secs, I’m having this communication error, because the heartbeat cant pass through when I’m querying from the database. The heartbeat only check 3 times and if it does not pass, it will be confused and throw communication error, but that only 30 secs for a total. (10 sec x 3 times heartbeat checking). This is really my big problem now, What I did is I set the heartbeat to 3 mins… and now my program cant verify if the user is still active for that 3 mins unless the hearbeat checks. Hope you can give me a suggestion or any way that I can solve this issue,… thank you in advance,
Can you move your query to a background thread? that way the session wouldn’t be locked… of course you need either push or poll to update the UI once the thread has run.
This might also be a good case for the Progress Indicator (or progress bar with temporary “manual” polling) as the polling would just affect the time the big data is loading and can be turned of right afterwards.