We have a java web application which was hosted in tomcat 8. For session Management , we have been using the memcache which maintains non sticky based sessions. This has been working fine without any issues.
Now there is a requirement to upgrade the tomcat from 8 to tomcat 9 and the upgradation with the necessary jars for the tomcat 9 has been done. After the upgradation, we are facing an issue in the application where the session is becoming null. Some of the link in the app associated with the session are working fine and some of them when clicked gets me logged out of the session. Checking the logs, I see the session object null.
The memcached jars used as part of the tomcat 9 and copied under tomcat9/lib
memcache-session-manager-2.3.2
memcache-session-manager-tc9-2.3.2
jettison-1.1.jar
spymemcached-2.12.0
http-core-4.3
http-core-nio-4.3
we are using the 3rd party Serialization for this use case and they are also copied in the tomcat lib folder
kryo-3.0.3.jar
kryo-serializers-0.37.jar
minlog-1.3.0.jar
msm-kryo-serializer-1.9.3.jar
objenesis-2.1.jar
protobuf-java-2.6.1.jar
reflectasm-1.10.1.jar
With these jars , I am able to see the tomcat startup without any issues.
**<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:ip:port"
lockingMode="auto"
sticky="false"
requestUriIgnorePattern= ".*\.(png|gif|jpg|css|js)$"
sessionBackupAsync= "false"
sessionBackupTimeout= "100"
copyCollectionsForSerialization="false"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>**
Followed the below link for setting up the memcache configuration in my application.
https://github.com/magro/memcached-session-manager/wiki/SetupAndConfiguration
Please help me if i am missing anything in the configuration.
Thanks
Pradeep
Have solved this issue by removing the param **requesturiignore pattern ** from the context.xml as this was creating different sessions.
Related
Tried using DistributedObjectCache for sharing data between clusters in WAS liberty server.
I have configured things based on IBM Distributed Map
I used Method 5 from the link, my server version is 7 and web.xml version is 2.4
After the configurations on my "server.xml" and ibm-web-bnd.xmi, I have used the below code to get the map instance on the application start.
DistributedObjectCache dm1a =(DistributedObjectCache)ic.lookup("java:comp/env/dmap/LayoutCache");
the dm1a is always null
As the servlet cache is used for caching JSP pages. etc, I need to cache java object so I used DistributedObjectCache
I am not sure that the .xmi file is getting read by the server, because I have tested by changing the webapp reference in there which was different from web.xml, but no error was thrown on the server startup
Is there anything i am missing?
I am migrating a legacy web application from Jboss AS7.1 to Wildfly 8.2. The application works perfectly on AS7. It stores a User object in the session using session.setAttribute() and retrieves it in various places where it needs to know the user details.
The application works fine on the first start of the Wildfly server. When I re-deploy the application (from Eclipse) it then fails when retrieving the session attribute with a ClassCastException (com.mycompany.User cannot be cast to com.mycompany.User). I cannot run the application without restarting the server completely. The application is a basic war deployment with a few dependencies in the lib folder.
I've run in debug and dumped the classloader name and can't see any problems. There is only 1 version of the User class in the application (it's inside a jar in the WEB-INF/lib folder). If I retrieve the session attribute as an Object and check 'obj instanceof User' it returns false. It seems to be holding onto something between deployments somehow but I can't find out what.
Has anyone come across anything similar?
Thanks
I have a problem where every time I redeploy my app, any existing sessions are broken and the requests result in a ViewExpiredException. None of the advice in related questions or outside mailing list / forum posts seems to fix this issue. I can redeploy the same WAR file completely unchanged and the behavior is the same.
I'm using Apache MyFaces 2.2.0, Tomcat 7.0.56 and Primefaces 5.0.
The message of the exception is No saved view state could be found for the view identifier: with whatever page would be requested. Primefaces' menubar is used for navigation, which seems to be implemented as a <form> with POST requests. These messages occur both with those navigation options and other AJAX that uses POST.
I have tried:
Setting explicit org.apache.myfaces.SECRET and org.apache.myfaces.MAC_SECRET values, as seen in this document.
Both client and server values for the javax.faces.STATE_SAVING_METHOD parameter.
Ensuring all beans and their transitive fields are serializable. No serialization errors are reported in the logs.
Using a filter to add no-cache headers, e.g. as suggested in this answer.
Session persistence is not disabled, that is my context.xml has <Manager pathname="" /> commented out.
try with:
<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="true"/>
It seems that losing sessions is a "feature" of Tomcat since at least version 6 and continuing to version 7 when deploying via WAR file. We have to copy an unpacked directory to avoid losing the sessions, because WAR changes cause an undeploy followed by a deploy, as opposed to a reload.
This bug report states:
There are ways to achieve an update to an application without dropping the sessions. The simplest is probably:
- deploy as an exploded directory rather than a WAR
- update the files
- touch web.xml to trigger a reload
The reason for the current behaviour is to prevent problems when WARs are updated in incompatible ways and anything other than a full undeploy followed by (essentially) a new deployment causes conflicts.
This is still the case in the current Tomcat 7.0 documentation:
Currently, application reloading (to pick up changes to the classes or web.xml file) is not supported when a web application is deployed directly from a WAR file. It only works when the web application is deployed from an unpacked directory.
I'm wrestling with a strange problem: When I make a change to a POJO or Seam Component in my localhost JBoss instance, restart it, and load the page, the change is visible. However, on our server, running the same version of JBoss, when I stop the instance, delete the WAR file, upload the latest version, and restart JBoss, it won't show some of the new server-side functionality.
Specifically, the change is to a POJO class which implements javax.faces.validator.Validator class. It's then used in the XHTML Facelet like this:
<h:inputText value="#{outsideaccount.accountOrganizationEmail}" maxlength="50"
id="txtOrganizationSupportEmail"
validatorMessage="Organization Support Email is not valid. It must be in the pattern 'some_id#some_domain.com'.">
<f:validator validatorId="AnyEmailValidator"/>
</h:inputText>
I'm able to use the email validator on my localhost JBoss correctly; on the development server, it throws a validation error using the same email on the same page. Very strange. Is JBoss caching the class files somewhere? How do I clear everything out of the JBoss development server cache?
I'm using Win XP Pro locally; the development server is using JBoss 4.2.3.GA on JVM Version 1.5.0_16-b02, with Unix SunOS 5.10. Thanks.
JBoss has work and tmp directories that you can delete to make sure everything is clean. Things can get cached there, so you can clear them out on deploy if you are having problems. There is also a setting to force that to happen automatically on JBoss's end. If your problem is a cache clearing problem, this will help solve it.
Another possibility is that you have two copies of that war deployed on JBoss, although that should give you some errors when you deploy in production.
I need to prevent Session Fixation, a particular type of session hijacking, in a Java web application running in JBoss. However, it appears that the standard idiom doesn't work in JBoss. Can this be worked around?
This defect (found here) points the way to the solution. The Tomcat instance that runs in JBoss is configured with emptySessionPath="true", rather than "false", which is the default. This can be modified in .../deploy/jboss-web.deployer/server.xml; both the HTTP and AJP connectors have this option.
The feature itself is used to eliminate the context path (eg. "foo" in http://example.com/foo) from being included in the JSESSIONID cookie. Setting it to false will break applications that rely on cross-application authentication, which includes stuff built using some portal frameworks. It didn't negatively affect the application in question, however.
This problem and the specific case in which it occurs is a problem in Tomcat as well as JBoss. Tomcat shares the emptySessionPath="true" effect (and actually JBoss inherits it from Tomcat).
This really seems like a bug in Tomcat and JBoss when you are trying to prevent session fixation attacks but the servlet spec (at least version 2.3) does not actually require the JSESSIONID to be defined or redefined according to any specific logic. Perhaps this has been cleaned up in later versions.
One workaround is to store the client address in the session. A response wrapper should validate the client address set in the session is same as the one accessing the session.
I came to know below code setting snippet from one of the forum. And I added below lines. But when I print the session ID after and before log in into the application it is same. How would I test session Fixation.
D:\jboss-5.1.0.GA\bin\run.cof file and add the below line.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false"
in each context.xml of the jboss applications.
D:\jboss-5.1.0.GA\server\default\deploy\jbossweb.sar\context.xml