[JBoss-user] [Clustering/JBoss] - Re: Http Session replication problems when NOT using sticky-
After some very careful testing of whether invalidate() and removeAttribute() are successfully replicated to cluster nodes other than the one where they were executed, we found that this reliably didn't work in a non-sticky-session configuration. The same tests worked correctly when we converted our test cluster to sticky-session, so we're in the process of converting our production cluster to use sticky-session. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3930448#3930448 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3930448 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Cluster error: failed to replicate session
We had a melt-down on our production JBoss cluster this morning. The errors being logged (1000s of times) were this: anonymous wrote : | 2006-03-15 07:31:41,612 ERROR [org.jboss.cache.lock.IdentityLock] write lock for /JSESSION/localhost/sunOLM2/hxCHnkvAh4ZboOrlmGqzSg** could not be acquired after 15000 ms. Locks: Read lock owners: [] | Write lock owner: g1apiapp4:54077:49603 | (caller=g1apiapp5:58563:119341, lock info: write owner=g1apiapp4:54077:49603 (activeReaders=0, activeWriter=Thread[MessageDispatcher up processing thread,5,jboss], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) | 2006-03-15 07:31:41,614 INFO [STDOUT] org.jboss.cache.lock.TimeoutException: write lock for /JSESSION/localhost/sunOLM2/hxCHnkvAh4ZboOrlmGqzSg** could not be acquired after 15000 ms. Locks: Read lock owners: [] | Write lock owner: g1apiapp4:54077:49603 | (caller=g1apiapp5:58563:119341, lock info: write owner=g1apiapp4:54077:49603 (activeReaders=0, activeWriter=Thread[MessageDispatcher up processing thread,5,jboss], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)) | 2006-03-15 07:31:41,616 INFO [STDOUT] at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:174) | 2006-03-15 07:31:41,617 INFO [STDOUT] at org.jboss.cache.Node.acquireWriteLock(Node.java:518) | 2006-03-15 07:31:41,618 INFO [STDOUT] at org.jboss.cache.Node.acquire(Node.java:475) | 2006-03-15 07:31:41,618 INFO [STDOUT] at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:242) | 2006-03-15 07:31:41,619 INFO [STDOUT] at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:153) | 2006-03-15 07:31:41,619 INFO [STDOUT] at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:41) | 2006-03-15 07:31:41,620 INFO [STDOUT] at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) | 2006-03-15 07:31:41,620 INFO [STDOUT] at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:41) | 2006-03-15 07:31:41,621 INFO [STDOUT] at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:54) | 2006-03-15 07:31:41,621 INFO [STDOUT] at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:3116) | 2006-03-15 07:31:41,622 INFO [STDOUT] at org.jboss.cache.TreeCache.put(TreeCache.java:1762) | 2006-03-15 07:31:41,623 INFO [STDOUT] at sun.reflect.GeneratedMethodAccessor298.invoke(Unknown Source) | 2006-03-15 07:31:41,623 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | 2006-03-15 07:31:41,624 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:585) | 2006-03-15 07:31:41,624 INFO [STDOUT] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) | 2006-03-15 07:31:41,625 INFO [STDOUT] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) | 2006-03-15 07:31:41,625 INFO [STDOUT] at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) | 2006-03-15 07:31:41,625 INFO [STDOUT] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) | 2006-03-15 07:31:41,626 INFO [STDOUT] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) | 2006-03-15 07:31:41,626 INFO [STDOUT] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176) | 2006-03-15 07:31:41,627 INFO [STDOUT] at $Proxy85.put(Unknown Source) | 2006-03-15 07:31:41,628 INFO [STDOUT] at org.jboss.web.tomcat.tc5.session.JBossCacheService._put(JBossCacheService.java:433) | 2006-03-15 07:31:41,628 INFO [STDOUT] at org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:229) | 2006-03-15 07:31:41,629 INFO [STDOUT] at org.jboss.web.tomcat.tc5.session.SessionBasedClusteredSession.processSessionRepl(SessionBasedClusteredSession.java:165) | 2006-03-15 07:31:41,629 INFO [STDOUT] at org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:606) | 2006-03-15 07:31:41,630 INFO [STDOUT] at org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:375) | 2006-03-15 07:31:41,630 INFO [STDOUT] at org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:38) | 2006-03-15 07:31:41,631 INFO [STDOUT] at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) | etc... | and this: anonymous wrote : | 2006-03-15 07:31:41,638 ERROR [org.jboss.web.tomcat.tc5.session.JBossCacheManager] processSessionRepl: failed with exception: java.lang.RuntimeException: JBossCacheService: exception occurred in cache put after retry ... | 2006-03-15 07:31:41,639 WARN [org.jboss.web.tomcat.tc5.session.InstantSnapshotManager] Failed
[JBoss-user] [Clustering/JBoss] - Re: Http Session replication problems when NOT using sticky-
I'm sure that the scenario you describe will work, but the whole point of this thread is that I'm trying to make the cluster work when it's not using sticky-session. Is thre any way I can push the removeAttribute or invalidate to the other node without shutting down? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3927775#3927775 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927775 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Http Session replication problems when NOT using sticky-
My test application uses struts, but the session attribute I'm using as a
marker is not used by struts.
I have 2 JSP pages. Each displays the name of the host that served it, and then
lists the name/value of all session attributes, like so:
| %
| java.util.Enumeration enm = session.getAttributeNames();
| while(enm.hasMoreElements())
| {
| String attr = (String)enm.nextElement();
| out.println(Session variable: + attr + value: +
session.getAttribute(attr) + br /);
| }
| %
|
On one page I have a button that sets the marker session attribute, then
another button (logout) that removes the attribute, then invalidates the
session and forwards to the other page:
| HttpSession session = request.getSession(false);
| if(session != null)
| {
| session.removeAttribute(marker);
| session.invalidate();
| }
|
The second page allows me to make another request and forwards back to the
first page. The first page reliably redisplays the marker session attribute,
which was removed, the the session invalidated (on the other cluster server) by
the previous request
Since I am running this on a two server cluster, using (mod_jk) equal weighted,
round-robin load balancing, the requests are served first by one server, then
by the other. Session is invalidated on one server, then displayed by a JSP
page which executes on the other server. I always display the name of the
server which ran each page just to confirm where the page was executed.
John
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3927610#3927610
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927610
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Http Session replication problems when NOT using sticky-
I just found a parameter in jbossweb-tomcat55.sar/META-INF/jboss-service.xml which looked as though it should fix my problems: | !-- A flag indicating if the local vm session value should be used if | it exists. When true, the existing vm local session values are used and | updates are replicated, but updates to the same session on other nodes | do not update the local session value. This mode is only useful for | failover. When false, the session value is obtained from the distributed | cache. This mode can be used with load balancing. | -- | attribute name=UseLocalCachetrue/attribute | This looked like it should solve my problems, but I changed the value to false and it didn't make any difference :-( John View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3927620#3927620 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927620 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Http Session replication problems when NOT using sticky-
I now have a simple test application which reliably shows that if I attempt to remove either a session (using HttpSession.invalidate()) or a session attribute (using HttpSession.removeAttribute(String)), the change is not immediately made on the remote cluster node. I am testing to find out how long it is before the session is removed on the remote node. Should I open a bug report for this issue (supported by the test application) or is this not considered a bug? Can anyone suggest any changes I can make to fix this issue, or to shorten the time between when a session is invalidated on one cluster node and when the same session is invalidated on other nodes in the cluster? Switching to using sticky-session is the obvious fix, but that will cause other problems in our environment Thanks - John View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3927322#3927322 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3927322 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [JBossCache] - Re: Message discarded from non-member
I've seen this problem, caused by having another JBoss machine on the same network, using the same mcast address and port, but a different partition name. Remember also that the all configuration creates two cluster partitions, one defined in cluster-service.xml, the other in tc5-cluster-service.xml John View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3925934#3925934 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3925934 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Http Session replication problems when NOT using sticky-sess
I have a JBoss cluster, v4.0.3, with two nodes. Load balancing uses mod_jk, but
without sticky-session.
I am having problems when a session is invalidated and then a new set of
attributes set in a new session (i.e. someone logs out, then logs in again as a
different user).
HttpSession sess = request.getSession(false);
| if (sess != null)
| {
| sess.invalidate();
| }
| sess = request.getSession(true);
| sess.setAttribute(Constants.USER_KEY, userInfo);
|
My testing shows that the session that is invalidated isn't being removed on
the other cluster node (not the node where this code is actually run). The
result is that the new user who's logged in sometimes sees data from the
previous user.
Searching the JBoss site, this is the document which has the most information
about what I'm seeing:
http://www.jboss.org/developers/projects/jboss/tc5-clustering.html
An extract follows:
anonymous wrote : Note that because of the dual use of in-memory and
distributed store sessions and because JBossCache does yet not support the
notion of modification event only from remote node(s), the current usage of
session replication must use sticky session. That is, only one dedicated
clustering node will handle the session request unless there is a failover.
This should not pose as a severe restriction since it will be rare indeed that
sticky session is not used in production today. We will relax this restriction
in the future release.
My question is, does this mean that we have to use sticky-session, because
otherwise, changes to a session on one cluster node won't necessarily be
visible on the other cluster nodes?
I have snapshot-mode set to instant and cache-mode set to REPL_SYNC
Any help or suggestions much appreciated
John
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3925963#3925963
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3925963
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Http Session replication problems when NOT using sticky-
We are trying to avoid using sticky-session because that would mean that we also have to use it on the two hardware load-ballancers in front of the cluster and web servers. The Operations group doesn't want to make this change... Replication-granularity is set in the jboss-web.xml file and we're not setting it, so the default must be used (is the default session?) John View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3925973#3925973 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3925973 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Farm not replicating an updated WAR file
I am running a JBoss cluster with 2 members, running JBoss 4.0.2. and JDK 1.4.2_09 The configuration is very close to the all configuration in the standard distribution. I am having intermittent problems where a WAR file deployed in the farm directory on one cluster member is not being copied to the other cluster member. On the server where the WAR file is updated, the WebApp is redeployed. On the other server, the WebApp is undeployed but never deployed again. I expect that the reason it isn't redeployed is that the WAR file isn't copied to the farm directory (by the JBoss farm), even though the previous version of the WAR file is deleted. I fixed the problem by deleting the WAR file from the first server, where it deployed successfully. Standard Undeploy messages on this server, and an undeploy message on the other server, where it never deployed, which is interesting... Next I redeployed the WAR file (again) on the first server and the webApp was successfully redeployed on BOTH servers this time - like I said, the problem is intermittent :-( Has anyone else experienced this problem or have any ideas what might be causing it? I don't have much information about what's going on yet - what logging should I turn on to find some clues? Thanks in advance John View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3901921#3901921 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3901921 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Do different Cluster Partitions need different multicast IP
I am running several JBoss 4.0.2 clusters on the same sub-net. Only HttpSession is clustered. The cluster membership is set using -Djboss.partition.name=foo when I start JBoss. My problem is that although the clusters have different names, it seems that every server is part of the same partition. All HttpSession objects are replicated to all cluster servers, even though the servers are in 3 different partitions. All cluster servers are using the same multicast IP address (UDP multicast) Am I misunderstanding how to seperate clusters? Do I need to use different multicast IP addresses, aswell as different partition names, for different clusters? Thanks! John View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3899133#3899133 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3899133 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: Do different Cluster Partitions need different multicast
That explains what we've been seeing, and may explain some unreliability with replication of deployments made to the farm directory. I'll make the changes and start testing again Thanks! John View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3899136#3899136 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3899136 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS JBossMQ] - No ManagedConnections available within configured blocking t
View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3821319#3821319 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3821319 I am developing a JMS application on JBoss. I have a Queue, which I post messages to, from a custom MBean, to be received by an MDB running in a J2EE application in the same JBoss server. My problem is that I can't close the JMS connections I use, even though i call close() on the JMS Session and Connection, so the system eventually runs out of JMS connections in its pool (I can see this with the jboss.jca.ManagedConnectionPool MBean, named JmsXA) Since I'm running in the MBean, I have to create a UserTransaction before I put a message on the queue, otherwise it complains about an invalid TransactionId. This works - don't know if it's relavent. My code is roughly this (- the exception handling): private QueueConnectionFactory qFactory = null; private QueueConnection qConnect = null; private QueueSession qSendSession = null; private QueueSender qSender = null; // Create a QueueSender InitialContext jndi = new InitialContext(); qFactory = (QueueConnectionFactory)jndi.lookup(JMS_FACTORY); qConnect = qFactory.createQueueConnection(); qSendSession = qConnect.createQueueSession(true, Session.AUTO_ACKNOWLEDGE); // transactional queue = (Queue)jndi.lookup(myQueueName); qSender = qSendSession.createSender(queue); // Use the sender // Close the session and connection if(qSender != null)qSender.close(); if(qConnect != null)qConnect.close(); Does anyone know what I have to do to release/destroy the connection? The connection pool MBean says that I haven't destroyed and connections, and 20 are in use when it runs out Thanks - John --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
