Issue with super fast requests

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  sessionBackupAsync="false"
2.  sessionBackupTimeout=100
3.  Set a value in the session
4.  Issue a 302 redirect to the user to send them to a different page
5.  Browser returns to the site and the state (using Spring Webflow) is invalid.

This issue only happens when the user returns to the site very quickly, usually 
only with a 302 redirect.

If we put a 1s sleep/delay before redirecting the user then this issue goes 
away.

My assumptions is that the session would be written to memcached BEFORE the 
response is returned to the user.  It appears that the session data is being 
written to memcached sometime AFTER the response is returned to the user.

Any insights on this?  Just to be silly, I'll do a $20 bounty via PayPal if 
someone can solve this.

We are running about 60 machines in Amazon EC2 and this is a really nice sized 
environment.  This project is really giving us great things like zero downtime 
deploy and auto-scaling without sticky sessions.  This is the only issue we've 
had thus far.

Original issue reported on code.google.com by mcon...@ccnag.com on 23 Jan 2015 at 3:40

[GoogleCodeExporter]

With your configuration (async false) the session *should* be stored in 
memcached before the response is returned. 
Can you reproduce this issue with debug logging enabled (see 
https://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration#C
onfigure_logging) and share logs from the involved tomcats?

Original comment by martin.grotzke on 23 Jan 2015 at 10:07

[GoogleCodeExporter]

Disclosure: I know the original poster and am a bit closer to the issue

I have created a project on github that is able to demonstrate the issue.
https://github.com/tyrinslys/spring-webflow-memcache

Running the example if all things were in working order I would expect to get a 
heap space error.

Instead I get an error from the flow controller that the specific snapshot can 
not be found.

Caused by: 
org.springframework.webflow.execution.repository.snapshot.SnapshotNotFoundExcept
ion: No flow execution snapshot could be found with id '2583'; perhaps the 
snapshot has been removed?

It seems to happen at random.

As a summary here is what this bug demo webapp is doing:
1. creating a map and placing it in session (sessionMap)
2. grab sessionMap and add one Integer pair to it (not a replace but mutating 
the map in session)
3. starting the flow
4. setting a counter in flow scope
5. issuing a redirect using the redirect directive (this actually sends a 302)
6. browser then requests the new url
7. same as step 2
8. add 1 to the counter in scope (then log it)
9. return a vew that has a meta redirect
10. browser calls server again
11. loop back to step 2 only we are not starting another flow... but continuing 
the existing flow.

I'll update if I find a certain version mix to fix the issue.

Original comment by tyrins...@gmail.com on 4 Feb 2015 at 10:00

[GoogleCodeExporter]

So... ignore me for a while. It appears I had settings incorrect and the 
example project doesn't illustrate the issue. I'll get back

Original comment by tyrins...@gmail.com on 5 Feb 2015 at 2:01

[GoogleCodeExporter]

Ok.

Original comment by martin.grotzke on 5 Feb 2015 at 2:41

[GoogleCodeExporter]

First I want to make sure my assumption is correct, please confirm the 
following.

If sessionBackupAsync="false" is in the config then the system behavior should 
be the same as using the default tomcat session manager (when looking from the 
point of view of the browser).

If that is not the case then please provide more information.

So an issue I was able to bring out with my example project is that when I run 
more than one flow at a time the conversation is lost.

Summary:
The problem is that no more than 1 flow is able to run at a time, without error.
Caused by: 
org.springframework.webflow.execution.repository.snapshot.SnapshotNotFoundExcept
ion: No flow execution snapshot could be found with id '58'; perhaps the 
snapshot has been removed?

Running Tomcat without memcache allows the max configured webflows to run 
without issue. Once past that we get a NoSuchConversationException which is 
expected as the first created webflow is deleted from session.
Caused by: 
org.springframework.webflow.conversation.NoSuchConversationException: No 
conversation could be found with id '1' -- perhaps this conversation has ended?

To recreate this run the following link in multiple tabs with the example 
project.
http://localhost:8080/spring-mvc-showcase/flow/testFlow?debug=grow

Oh and here is version information:
apache-tomcat-7.0.57
memcached-session-manager-1.8.2.jar
memcached-session-manager-tc7-1.8.2.jar
spymemcached-2.11.1.jar

Original comment by tyrins...@gmail.com on 9 Feb 2015 at 8:02

[GoogleCodeExporter]

I have even tried lockingMode="all" which I think would make sure simultaneous 
threads are not causing issues, but the issue is still found.

Original comment by tyrins...@gmail.com on 10 Feb 2015 at 4:19

[GoogleCodeExporter]

Re sessionBackupAsync="false": yes, the system behavior should be the same as 
using the default tomcat session manager (when looking from the point of view 
of the browser).

I checked out your project and ran 
http://localhost:8080/spring-mvc-showcase/flow/testFlow?debug=grow, which is 
then counting and counting (I stopped at "Count now is 712").

What can I do to reproduce your issue?

Btw, great that you've setup the sample project!

Cheers,
Martin

Original comment by martin.grotzke on 10 Feb 2015 at 9:46

[GoogleCodeExporter]

Looks like you got the project setup. To test you run that url in 2 tabs so the 
same session is being edited by both tabs.

I took the liberty of adding the lockingMode="all" to the context file in the 
project as I thought that would solve the issue.

I believe the problem shows itself when 2 requests for memcache-session happen 
at the same (similar) time.

Again with memcache configured in tomcat with the provided context the example 
does not work... and removing it, which uses tomcat session management, the 
issue magically is gone.

Please remember the context file is not automatically deployed but must be 
copied to the tomcat home config dir and a tomcat restart issued.

Let me know if you still have issues, and I will be happy to assist.

Original comment by tyrins...@gmail.com on 10 Feb 2015 at 10:30

[GoogleCodeExporter]

Ok, this way I can reproduce the issue. One important thing is that you're 
using non-sticky sessions, which means that a session is only stored in the 
tomcat internal session map for the duration of a request. I'd say that using 
lockingMode="all" should solve concurrency issues, I need to think about it 
what might be the issue. Perhaps there's also an issue with web flow 
serialization, I'd need to understand the internals of webflow and how things 
are serialized/restored. Finally I'd say it doesn't seem to be easy to be 
solved but needs some deeper investigation.

Do you need non-sticky sessions, or could you just use sticky sessions?

Original comment by martin.grotzke on 11 Feb 2015 at 9:03