It means when your client is subscribed to push but don't request any JSF, view state is lost, right?
We can simply reproduce that with opening any page using a4j:push but pushing no data, right?
Hello Lukáš Fryč,
I'm sorry that I don't seem to be clear about it. I'll try to explain better.
Normally everything is fine. It runs for days and even when the user is not doing anything it keeps functioning without any problem. But sometimes the memory usage starts rising enormously (in my case happens once every couple of weeks). From 150MB to even 900MB in 'CMS Old Gen' heap space. I can't be sure that there is any relation between lost viewstates and the memory hunger. It just makes sense because that is what I saw the last time. It happened both at the same time.
Normally the client reacts in some way to the push but it is normal that nobody has a view active that listens to the push topic being sent.
To replicate I guess you could somehow force a lost view state and then keep pushing events.
I was pushing an event every 20 seconds but somehow the heap dump contained a lot more. I can see where they came from based on the topicKey. 3 a minute x 60 x 10 hours = 1800 pushes max. But I see millions. Where did they come from?
Is it an idea to add an age to the push events and drop them if they are too old? Or just a max queue size.
in org.richfaces.application.push.impl.SessionImpl I see a messagesQueue that seems to be cleared based on sequenceNumber. Could it be that the sequenceNumber is not incremented somehow?
Milo van der Zee
both are pretty valid ideas.
Let's create issue which will address the problem with setting up proper tests:
If you could think about any other test cases which are worth to test, let's brainstorm there.