I would like to totally disable session creation and management in my web app to eradicate the memory (and other resource) usage currently associated with Tomcat's standard session manager. This includes disabling sesison cookies and/or url rewriting as, if I'm succesful, there will be no sessions to track.
My web application has a single servlet that passes the xml it receives to an API/engine. This engine can run inside or outside a servlet container and it creates, tracks and manages sessions in its own way. I have zero need for the sessions in Tomcat and I'd like to reduce to the barest minimum the resources Tomcat uses for session management.
I ran some searches on the topic. The searches came up with some topics, including some on this website. It appears that the tightest way to address this issue is to create your own Manager implementation that, bascially, provides an 'empty' implementation that does the barest minimum. (There were some alternative suggestions but I found them to be relatively weak. These suggestions included "just don't call getSession()", and "set the 'cookies' attribute of a context to false". I think implementing a session manager that does what I want is better than these suggestions and it is the path I have elected to go down.)
Given this information, that rolling your own session manager is a good way to go, I then downloaded the Tomcat source code to take a look at code related to a Manager implementation. It all looks doable but it looks like a few hours work for me to come up with my attempt at a sesssion manager. Before committing to that path and the work involved, I thought I'd put it out there - Does anyone have a minimal session manager implementation for Tomcat they can share? One that does nothing would be best, but I'll take anything including tips and battle stories from anyone who has written their own session manager. I am working with Tomcat 6.
Related
I have multiple web applications running under a single Tomcat container. Since they all run under a single Tomcat connector (as defined in the server.xml file), attributes such as maxConnections and maxThreads govern the container as a whole. As a result it is possible for a single application to consume all available Tomcat threads, starving the other applications of threads and making them unresponsive. I would like to be able to define the maximum http threads on a per context basis so that this is no longer possible.
Here's what I've tried so far:
Create a custom filter in the application that keeps track of the current thread count and limits additional connections. (Got the filter here: How to set limit to the number of concurrent request in servlet?). I'm not sure I like this solution, as it isn't as full-featured (support for attributes such as acceptCount, maxConnections, maxThreads, and minSpareThreads) as Tomcat provides by default to the container; and adding in the features feels like I am attempting to build what already exists in Tomcat.
Create a separate Tomcat connector in the server.xml file for each context. This has a few issues. For one, each connector requires a separate port; this means I'll have to account for this in my apache config. Secondly, I plan to add more webapps regularly; this means a config change followed by a tomcat restart, which is disruptive to clients.
Has anyone else encountered something like this? I feel like there should be a "Tomcat supported" workflow to accomplish what I'm after.
I'm going to post an answer that was provided to me from the Tomcat user group: http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Semaphore_Valve (The Semaphore Valve is not Tomcat 9 specific, but was actually introduced in Tomcat 6). I experimented with this concept, and I found the following practical applications:
(Untested) The Semaphore Valve should be able to be nested within the Host element in the server.xml file.
(Tested) A [context-name].xml file can be placed inside [tomcat-home]/conf/Catalina/localhost with the valve nested within the Context element.
This is not necessarily the solution that I am going with, as more testing will need to be performed. However, I thought I'd add this as it is a potential answer to the problem.
Update:
As a recap, the SemaphoreValve was an option that was recommended to me through the Tomcat user mailing list as a solution to the issue that I described above. It turns out it was easier to implement than I anticipated. Adding the following to context.xml in the Tomcat/conf directory did the trick:
<Valve className="org.apache.catalina.valves.SemaphoreValve"
concurrency="10"
fairness="true" />
Thanks to Mark Thomas from the Apache group for supplying the solution.
I have the requirement to save some information across restarts and redeployments, i.e. write it to a file when Tomcat is shut down and restore it from the file when it is started. It's similar to the way Tomcat saves session information across restarts (see Persistence Across Restarts).
What's the correct directory for such a file?
What's the API to get the path to this directory?
I'm looking for a solution that works on different operation systems, works across redeployments and does not require any setup or configuration tasks. It should be as simple as Tomcat's session persistence, which just works without any configuration.
Use ServletContextListener - Interface For handling your backup plan.
ServletContextListener - contextDestroyed(..) & contextInitialized(..)
And for Handling Path while store file inside Tomcat-server,
Use this code for retrieving path, request.getRealPath("/").toString()
Above getRealPath("/") will provide you server's log directory path. please change it accordingly whatever nearest you want.
Let me know whether this help in your scenario or not ?
I am unable to configure/change the Map(declared as part of hazelcast config in spring) properties after hazelcast instance start up. I am using hazelcast integrated with spring as hibernate second level cache. I am trying to configure the properties of map (like TTL) in an init method (PostConstruct annotated) which is called during spring bean initialization.
There is not enough Documentation , if there is please guide me to it.
Mean while i went through this post and found this Hazelcast MapStoreConfig ignored
But how does the management center changes the config, will it recreate a new instance again ?
Is hazelcast Instance light weight unlike session factory ? i assume not,
please share your thoughts
This is not yet supported. JCache is the only on-the-fly configuration data structure at the moment.
However you'll most probably be able to destroy a proxy (DistributedObject like IMap, IQueue, ...), reconfigure it and recreate it. Anyhow at the time of recreation you must make sure that every node sees the same configuration, for example by storing the configuration itself inside an IMap or something like that. You'll have to do some wrapping on your own.
PS: This is not officially supported and an implementation detail that might change at later versions!
PPS: This feature is on the roadmap for quite some time but didn't made it into a release version yet, it however is still expected to have full support at some time in the future.
In a J2EE application, we are using EJB2 in weblogic.
To avoid losing time building the initial context and looking up EJB Home interface, I'm considering the Service Locator Pattern.
But after a few search on the web I found that even if this pattern is often recommended for the InitialContext caching, there are some negative opinion about the EJB Home caching.
Questions:
Is it safe to cache EJB Home lookup result ?
What will happen if one my cluster node is no more working ?
What will happen if I install a new version of the EJB without refreshing the service locator's cache ?
Is it safe to cache EJB Home lookup
result ?
Yes.
What will happen if one my cluster
node is no more working ?
If your server is configured for clustering/WLM, then the request should silently failover to another server in the cluster. The routing information is encoded in the stub IOR.
What will happen if I install a new
version of the EJB without refreshing
the service locator's cache ?
Assuming you update the bean and not the component or home interfaces, then everything continues to work. EJBHome is effectively a stateless session bean, so the request can continue to be accessed from the same server if available or on a different server in the cluster if not.
Note that the #EJB injection in EJB3 effectively encourages home caching. (Though, admittedly, it also allows SFSB caching even though this is clearly incorrect, so perhaps #EJB isn't the best support of my claim :-)).
Is it safe to cache EJB Home lookup result ?
What will happen if one my cluster node is no more working ?
IMHO the purpose of ServiceLocator within J2EE is to cache EJB Home and reduce expensive JNDI look ups. It is safe on Weblogic since by default the EJB Home is load balanced across the cluster, and this will automatically allow failover to the next server.
This value is controlled by the home-is-clusterable value in weblogic-ejb-jar.xml, documented here which defaults to true.
What will happen if I install a new version of the EJB without refreshing
the service locator's cache ?
I havent tried doing such a change myself. However, I'm guessing as part of your build/deploy, your Service Locator class would also get redeployed along with a change to your EJBs - and thus do a fresh lookup?
If your client is unaffected during the changes to the EJB, then the cached EJBHome will return a stale reference when you call a method on it. So you will have to force the client to be refreshed.
What will happen if I install a new
version of the EJB without refreshing
the service locator's cache ?
Once your application goes live, new installations should become much less frequent than requests for an EJBHome.
So your focus and concern should lie with the frequent live operations, rather than the transient development operations.
Factor into your design the ability to invalidate caches when necessary.
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