https://bz.apache.org/bugzilla/show_bug.cgi?id=66513
--- Comment #11 from Vincent Liautaud <vincent.liaut...@free.fr> --- Hi, let me try to give more explanation on the context and the issue we faced. We are in a process where we move to the cloud (on Google Cloud Platform) some internal web application that currently run on premise, on several tomcat, all installed on different servers with a sticky session load balancer in front of them. Because on this sticky session Load balancer we don't use persistent valve on premise (session information are stored in JVM Tomcat Memory). When moving to GCP, we choose to containerise those applications and run them on a Google managed services named Cloud Run. Cloud Run is typically a serverless solution that run and scale containers (up and down) based on the volume of requests. As any solution that run and scale containers, you can't fully manage the ways the underlying solution (Cloud Run or K8S....) scale up and down the containers. Saying that, even if Google propose a solution that "looks like" a sticky session load balancer, this solution can't assure you 100% that all the requests of a same user will always target the same container (typically Google destroy sometimes some container because the volume of requests decrease, even if some users are "connected" to them. So, this kind of containerised infrastructure, need a solution to centralise and share the session informations beetween different containers, BECAUSE you can't be 100% sure that all requests of a same session will always be treated by the same container. That's why we used Persistent Valve to solve this issue. Now let's go back to the initial reason of raising this BZ tikcet : In our use case, persistent Valve fully solve our problem, because we have no more concurrent requests on the same session (no more on a single node than on multiple node). The ticket was raised because of another little bug described above (and repeated bellow) : When configuring PersistentValve we copied and pasted part of tomcat documentation explaining how to implement a filter : filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html| .*\.css|.*\.txt" This filter introduced a malicious space character before the .*\.css !!! resulting of having several concurrent requests (servlet but also CSS - badly filtered). In this configuration, the way persistentValve update the session information (by sequencing delete and insert SQL requests) genrated a kind of "PRIMARY KEY VIOLATION" on the database. As the synchonized block was useless (because of previous information given on the initial comments), with to concurrent request we were in a situation where : -Request 1 (Servlet) : DELETE session information -Request 2 (CSS) : DELETE session information -Request 1 (Servlet) : INSERT session information -Request 2 (CSS) : INSERT session information ******=> DUPLICATE KEY ERROR It took some time to us to identify the problem with the filter (and the missing space) => Because no debug log can be used to identify which request is treated by persistent valve (servlet or CSS or something else)....But since we solved this issue with the filter...It works fine. We don't have any more errors and persistentValve work very well even in a containerised environnement. Conclusion : Please don't deprecate this functionnity... And if possible add some debug information on the kind of request treated (would help to identify concurrent requests).... Thank's for all Regards -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
