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
acquire
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
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 :
h
I just found a parameter in jbossweb-tomcat55.sar/META-INF/jboss-service.xml
which looked as though it should fix my problems:
|
| true
|
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 or
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.get
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
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
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 =
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-servi
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 copi
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=bb&op=viewtopic&p=3899136#3899136
Re
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 partiti
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3821319#3821319
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3821319
I am developing a JMS application on JBoss. I have a Queue, which I post messages to,
from a custom MB
13 matches
Mail list logo