[JBoss JIRA] Created: (JBAS-3864) HttpSession replication does not always retry if replication fails
by Brian Stansberry (JIRA)
HttpSession replication does not always retry if replication fails
------------------------------------------------------------------
Key: JBAS-3864
URL: http://jira.jboss.com/jira/browse/JBAS-3864
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-4.2.0.CR1
If replication of a session fails, the session replication layer does not retry. This leaves the local session map in JBossCacheManager out of sync with the distributed cache. If there is a failover while the distributed cache is out of sync, the user will see stale data.
Need to retry a (configurable) X number of times. If the session still doesn't replicate, need to decide what to do -- i.e. is it too late in the request cycle to throw an exception and return an error to the client?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Created: (JGRP-587) Lightweight FLUSH for state transfer
by Vladimir Blagojevic (JIRA)
Lightweight FLUSH for state transfer
------------------------------------
Key: JGRP-587
URL: http://jira.jboss.com/jira/browse/JGRP-587
Project: JGroups
Issue Type: Feature Request
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Fix For: 2.7
We should investigate introduction of lightweight FLUSH in Multiplexer. Lightweight FLUSH would introduce stop-the-world model to only specific mux application leaving other mux applications unaffected. For example, if there are three mux applications A,B, and C and we need to FLUSH only application C, lightweight FLUSH would block all message sending for C only while applications A and B are unaffected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Created: (JGRP-520) OOM with RpcDispatcher
by Bela Ban (JIRA)
OOM with RpcDispatcher
----------------------
Key: JGRP-520
URL: http://jira.jboss.com/jira/browse/JGRP-520
Project: JGroups
Issue Type: Bug
Environment: 1.5.0_10-b03;Sun Microsystems Inc.;mixed mode, sharing;Windows;32 bit JVM
Windows Server 2003 Standard x64
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Critical
Fix For: 2.5
Attachments: SimpleClusterManager.java
[from Patrick Eger]
Attempting to isolate the problem, I ran into a (probably unrelated)
other OutOfMemoryError problem with JGroups 1.5b2. Got an
OutOfMemoryError after ~3 minutes of running the attached
TestJGroups.java, 3 instances in parallel. Also attached is the stack
config and a couple YJP views of the HPROF dump as generated by
-XX:+HeapDumpOnOutOfMemoryError.
The test is looping single-threaded, calling a remote method via
RpcDispatcher every 100 ms which returns a few KB String. Looks like all
the memory is retained instances of org.jgroups.stack.IpAddress
(~1,000,000 for a ~3 minute run (seems like a lot?)), held by
pbcast.NAKACK.sent_msgs. I have the HPROF dump if you need, its about 15
megs zipped so I assumed would not make it through the mail filters.
Is this a real OOME or is it a stack configuration/tuning thing? I have
used the default UDP config, but with increased thread_pool and
oob_thread_pool sizes.
Options
-----------------------------------------
-agentlib:yjpagent
-server
-Xmx64m
-XX:+HeapDumpOnOutOfMemoryError
-Dcom.sun.management.jmxremote
-Dpeer_cluster_manager.XXXTestClusterXXX.jgroups_config=C:\tmp\testcfg.x
ml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months