Looking at the error you're getting doesn't look like that has anything to do
with the 4k limitation on the blob data type in MySQL or JBCACHE-320. In the
blob case you'd get NPE upon truncation of the data stored.
I think the problem has to do with the serialization of the objects that you're
I had experienced the same error on one of our clusters (JBoss AS 4.0.5 and
JGroups 2.2.7 though). I solved the issue by upgrading JGroups to 2.4 which
fixed a deadlock issue as per http://jira.jboss.com/jira/browse/JGRP-292
I'm not sure if 2.2.9-beta has the same issue, just thought I'd share
Here's your problem
| worker.node1.host=node1._._._.209
|
this line should only have the host ip address or name and not node1._._._.209
Remove node1 and node2 from the your workers.properties file. The way it's
right now the host ip address is invalid and apache won't be able to resolve
From your last post, I thin you're missing the name space mapping. check your
uriworkermap.properities file under $apache_home/conf that's where the mod_jk
would know how to direct requests to which name space on the server for your
war.
if you don't have an entry similar to the one below,
I think you're trying to run the demo in 1.4.1.BETA
anonymous wrote :
| file:///B:/tools/JBossCache-1.4.1.BETA/docs/tutorial/en/html/index.html
|
from within 1.4.0.SP1 build with the wrong path to the ant runtime.
anonymous wrote :
| JBossCache-1.4.0.SP1 1266build.sh run.demo
|
And http://jira.jboss.com/jira/browse/JBCACHE-912 is resolved with status
'can't reproduce bug'
If you can't run the tutorials as per my last post, please reopen the issue
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3995637#3995637
Reply to the post :
The shell script already set $ANT_HOME variable local to the script. If you
uncomment the classpath line (line 6) in the script that would do exactly what
you're suggesting.
I'm not sure why this line is commented in the script!!
Anybody?
View the original post :
Are you sure this's your current cache configuration? It doesn't have even the
JDBC cache loader configuration which was in your first post?!!
Anyway, I think based on the your first post cache configuration that more than
one thread is accessing the data with read committed isolation level
I think you have a race condition going on here stems from your application
doing this call
com.sisl.ashleycomm.cache.CacheTimeoutManager.putCacheable(CacheTimeoutManager.java:452)
Are you using eviction policy? Can you post the entire JBossCache configuration
you're using?
what isolation
You don't need to change each occurrence. To change the partition name, pass
-Djboss.partition.name= to the server startup.
Check this wkik page:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ChangeClusterPartitionName
Hany Mesha
Novell Inc.
View the original post :
I think what you should be doing is clear the local cache using JBossCache
options API when undeploying your application. That will clear the cache and
then start a new instance on redeployment which will have the right classes
with the right defining class loader and you won't affect the other
you gut instinct is correct :) It should work either way. However, the servers
in the cluster that don't have their Http Session passivation turned on, will
not be able to passivate sessions maintained by their respective cluster
manager.
You can see the benefits, trade offs, and a whole lot
You must use binding manager to start more than one instance on the same
machine:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfiguringMultipleJBossInstancesOnOneMachine
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3988717#3988717
Reply to the post :
You probably have an object in your application trying to store
org.apache.log4j.Level instance in the session and that's why you're seeing the
stack trace below.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3987949#3987949
Reply to the post :
You can create a wrapper class around the session object that intercept calls
to setAttribute() and getAttribute() then using JBossSerialization serialize
your objects before writing them to the session and deserialize them on return.
Also, make sure that your wrapper class is thread safe so
It looks like you don't have sticky session enabled on the cluster. Please
check this wiki page on how to correctly configure apache with mod_jk and JBoss
Clustering http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingMod_jk1.2WithJBoss
View the original post :
16 matches
Mail list logo
