I deployed the HTTP Session management on WebShpere application as Peer to Peer model. I am trying to reset the defalut session timeout using cache-peer.xml file. However, it shows below error message.
java.lang.RuntimeException: EntryIdleTimeout is not the same
at com.gemstone.gemfire.internal.cache.xmlcache.RegionAttributesCreation.sameAs(RegionAttributesCreation.java:391) ~[gemfire-8.0.0.jar:na]
at com.gemstone.gemfire.modules.util.RegionHelper.validateRegion(RegionHelper.java:67) ~[gemfire-modules-8.0.jar:na]
at com.gemstone.gemfire.modules.session.common.PeerToPeerSessionCache.createOrRetrieveRegion(PeerToPeerSessionCache.java:130) ~[gemfire-modules-session-8.0.jar:na]
at com.gemstone.gemfire.modules.session.common.PeerToPeerSessionCache.initialize(PeerToPeerSessionCache.java:72) ~[gemfire-modules-session-8.0.jar:na]
at com.gemstone.gemfire.modules.session.filter.GemfireSessionManager.initializeSessionCache(GemfireSessionManager.java:415) ~[gemfire-modules-session-8.0.jar:na]
at com.gemstone.gemfire.modules.session.filter.GemfireSessionManager.start(GemfireSessionManager.java:132) ~[gemfire-modules-session-8.0.jar:na]
at com.gemstone.gemfire.modules.session.filter.SessionCachingFilter.init(SessionCachingFilter.java:536) ~[gemfire-modules-session-external-8.0.jar:na]
Cache-peer.xml
<region name="gemfire_modules_sessions">
<region-attributes scope="distributed-ack" enable-gateway="false" data policy="replicate" statistics-enabled="true">
<entry-idle-time>
<expiration-attributes timeout="600" action="invalidate"/>
</entry-idle-time>
</region-attributes>
</region>
Any idea? I could not find the defalut setting.
You should not use the region definition to control expiration, but rather the standard deployment descriptor semantics. For example in web.xml:
<session-config>
<!-- set session TTL to 30 seconds -->
<session-timeout>30</session-timeout>
</session-config>
The session expiration is still controlled by the native container which will emit the appropriate events when a session is created/destroyed. The GemFire HTTP Session Module registers a SessionListener and picks up these events, destroying the underlying cached session as necessary.
You can also set the TTL on an individual session through the Servlet API with:
HttpSession session = request.getSession();
session.setMaxInactiveInterval(30);
Related
I have used this jar to integrate redis with micronaut.
compile 'io.micronaut.configuration:micronaut-redis-lettuce'
By default, the redis health check is enabled even though i have disabled the health end point in my micronaut application.
https://micronaut-projects.github.io/micronaut-redis/latest/guide/
Below is the exception I am getting for every 100 seconds since I have configured the health interval as
micronaut.health.monitor.interval: 100s
Path Taken: new HealthMonitorTask(CurrentHealthStatus currentHealthStatus,[List healthIndicators]) --> new RedisHealthIndicator(BeanContext beanContext,[HealthAggregator healthAggregator],StatefulRedisConnection[] connections)
io.micronaut.context.exceptions.DependencyInjectionException: Failed to inject value for parameter [healthAggregator] of class: io.micronaut.configuration.lettuce.health.RedisHealthIndicator
Message: No bean of type [io.micronaut.management.health.aggregator.HealthAggregator] exists. Make sure the bean is not disabled by bean requirements (enable trace logging for 'io.micronaut.context.condition' to check) and if the bean is enabled then ensure the class is declared a bean and annotation processing is enabled (for Java and Kotlin the 'micronaut-inject-java' dependency should be configured as an annotation processor).
Path Taken: new HealthMonitorTask(CurrentHealthStatus currentHealthStatus,[List healthIndicators]) --> new RedisHealthIndicator(BeanContext beanContext,[HealthAggregator healthAggregator],StatefulRedisConnection[] connections)
at io.micronaut.context.AbstractBeanDefinition.getBeanForConstructorArgument(AbstractBeanDefinition.java:990)
at io.micronaut.configuration.lettuce.health.$RedisHealthIndicatorDefinition.build(Unknown Source)
at io.micronaut.context.DefaultBeanContext.doCreateBean(DefaultBeanContext.java:1494)
at io.micronaut.context.DefaultBeanContext.addCandidateToList(DefaultBeanContext.java:2507)
at io.micronaut.context.DefaultBeanContext.getBeansOfTypeInternal(DefaultBeanContext.java:2429)
at io.micronaut.context.DefaultBeanContext.getBeansOfType(DefaultBeanContext.java:854)
at io.micronaut.context.AbstractBeanDefinition.lambda$getBeansOfTypeForConstructorArgument$10(AbstractBeanDefinition.java:1088)
at io.micronaut.context.AbstractBeanDefinition.resolveBeanWithGenericsFromConstructorArgument(AbstractBeanDefinition.java:1697)
at io.micronaut.context.AbstractBeanDefinition.getBeansOfTypeForConstructorArgument(AbstractBeanDefinition.java:1083)
at io.micronaut.context.AbstractBeanDefinition.getBeanForConstructorArgument(AbstractBeanDefinition.java:962)```
Setting this parameter as false in application.properties solved it.
micronaut.health.monitor.enabled=false
Hi i have a Redis configured on my Spring project to use Spring Session, i'm using Jedis 2.9.0 and it works well. The problem I have is with the Sticky session on the Websphere Server, we have 2 main servers and 10 clones of each, with normal httpSession it uses the cookie to handle the request of that cookie to the same server again, good, but with Spring Session it doesn't work the same.
Spring create the cookie with the name "SESSION" and the Load Balancing of Websphere doesn't know where to redirect the request because the session is not on the JVM but is ditributed in Redis Cluster.
i need to (for log order porpuse) handle every request of cookie "abc123" to the server 1 clon 3 for example, and if that instance of the application goes down track that cookie to another instance and stay on that instance until the server goes down again or the user logout...
Searching here and the Spring Session doc, i found something that might be useful but I dont know how it works.
#Bean
public CookieSerializer cookieSerializer() {
DefaultCookieSerializer serializer = new DefaultCookieSerializer();
serializer.setCookieName("JSESSIONID");
serializer.setCookiePath("/");
serializer.setDomainNamePattern("^.+?\\.(\\w+\\.[a-z]+)$");
serializer.setJvmRoute("123");
return serializer;
}
The atribute Jvm Route adds a suffix to the cookie to know whats the JVM that handle that cookie, but i don't know how it works and I haven't been lucky finding examples or explanation about it.
if anyone have the answer or another workaround that i could use it will be great.
We are maintaining an application which uses Jboss as its AS. Recently customer complained about OOM error and he was unable to login. We restarted Jboss and added configurations to collect heapdump.
Customer's application usage pattern: Customer opens a page containing 10 charts which are rendered in an inframe. Flex is used for UI. This page refreshes itself every 5 minutes.
Request Flow: The application is built in such a way that all the requests go through Apache (Http) proxy server. Every 5 minutes the dashboard request has to pass through Apache proxy server.
After 5 days OOM error occurred and on analyzing the heapdump we noticed that the error was due to "org.apache.catalina.session.StandardSession", loaded by "org.jboss.mx.loading.UnifiedClassLoader3 # 0x7b440dd70" occupy 1,776,569,336 (87.71%) bytes.
Full description is:
847,599 instances of "org.apache.catalina.session.StandardSession", loaded by "org.jboss.mx.loading.UnifiedClassLoader3 # 0x7b440dd70" occupy 1,776,569,336 (87.71%) bytes. These instances are referenced from one instance of "org.apache.catalina.Session[]", loaded by "org.jboss.mx.loading.UnifiedClassLoader3 # 0x7b440dd70"
Keywords
org.jboss.mx.loading.UnifiedClassLoader3 # 0x7b440dd70
org.apache.catalina.session.StandardSession
org.apache.catalina.Session[]
Common Path To the Accumulation Point says:
java.lang.Thread # 0x7b4a5f358 ContainerBackgroundProcessor[StandardEngine[jboss.web]]
org.apache.catalina.session.StandardSession # 0x797b49b70
I am new to Jboss and proxy servers. How to debug this issue? Could you please help me.
Thanks
M
org.apache.catalina.session.StandardSession is a class representing user http session. I would say, that your every request creates new http session on JBoss which is never expired. Either pass session cookie back to JBoss with every refresh to reuse sessions and not to create new ones. Or configure sensible http session expiration policy in you JBoss.
Good luck,
Plumbr team
I'm looking to understand the behavior of the session properties that are defined in the following files
initOptions.js
// # Worklight server connection timeout
//timeout: 30000,
Does this parameter affect the client mobile app and disconnect the connection to the Worklight Server after the defined interval ?
worklight.properties
#####################################################################
# Idle session timeout in minutes
#####################################################################
#serverSessionTimeout=10
Does this override the Web Container session timeout property on the JEE server to close or destroy idle sessions after the given time interval ?
In initOptions.js, the timeout property relates to the amount of time the app will wait for a connection to the Worklight Server.
In worklight.properties, the serverSessionTimeout property does the following: http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html#setMaxInactiveInterval(int)
You can also take a look at this question: SessionTimeout: web.xml vs session.maxInactiveInterval()
In short, it does what you wrote.
I am migrating an application from JBOSS 4 to JBOSSAS 7. I followed the guide for migration, converted all the ejbs to ejb3 fixed the JNDI names. After I deploy the ear I see message that the EJBs are bound. After that it goes in a wait state and then just times out with this message:
JBAS015052: Did not receive a response to the deployment operation within the allowed timeout period [1200 seconds]. Check the server configuration file and the server logs to find more about the status of the deployment.
I turned on the logging to DEBUG, which gives me a few exceptions about Transaction and NIO etc (which after spending a lot of time in JBOSS message groups and this one, I found were harmless).
I don't know how to debug this. I got the stack dump of the process but all I see is that the deployment scanner was waiting on something. Not sure what :
"DeploymentScanner-threads - 2" prio=5 tid=0000000003d77400 nid=0xb6447000 in Object.wait() [00000000b6446000]
java.lang.Thread.State: WAITING (on object monitor)
Anyone know how to debug this ? I am pretty damm fraustrated at this point. I mean if it doesn't throw an error, how am I supposed to debug this ?
It is an old post but, if some of you have a similar problem, you can try increasing the deployment-timeout in your standalone.xml,
Find This block
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
<deployment-scanner path="deployments"
relative-to="jboss.server.base.dir"
scan-interval="5000" />
</subsystem>
Then add the attribute deployment-timeout (in seconds) to a value (like 20 minutes)
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
<deployment-scanner path="deployments" relative-to="jboss.server.base.dir"
scan-interval="5000" deployment-timeout="1200"/>
</subsystem>
look this for reference
JBAS015052: Did not receive a response to the deployment operation within the allowed timeout period [60 seconds]
It is a usual problem in overloaded environments.