[JBoss JIRA] Created: (JBCACHE-1432) Cache corrupted by 64bit windows member
by Bill Middleton (JIRA)
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.1.0
Hello. We've run into some trouble in attempting to bring a 64bit windows machine into an existing cluster. The cluster has (had) two 64bit linux members and was running fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the 64bit windows machine wrote a node, the node was thereafter unreadable by either of the original cluster members. Exceptions of the following form were thrown by the other members (will attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is running 64bit windows as a cluster member with other OS's in the cluster. I hope perhaps someone can at least confirm this now formally?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 5 months
[JBoss JIRA] Created: (JBCACHE-1449) Small lock confusion in CacheLoaderInterceptor
by Krzysztof Sobolewski (JIRA)
Small lock confusion in CacheLoaderInterceptor
----------------------------------------------
Key: JBCACHE-1449
URL: https://jira.jboss.org/jira/browse/JBCACHE-1449
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
I was doing another torture-test of one of my components based on JBoss Cache and noticed mysterious "can't lock node" exceptions. The test is very simple: 5 threads are trying to retrieve one node's key, 5 other threads try to delete it.
Long story short, I think the result is one the smallest fixed I've ever seen :)
Index: src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java
===================================================================
--- src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (revision 6986)
+++ src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (working copy)
@@ -245,7 +245,7 @@
{
NodeSPI n = dataContainer.peek(fqn, true, true);
Object lockOwner = lockManager.getLockOwner(ctx);
- boolean needLock = n != null && !lockManager.ownsLock(fqn, lockOwner);
+ boolean needLock = n != null && !lockManager.ownsLock(n, lockOwner);
boolean mustLoad = false;
try
{
It seems that when the node (n) is deleted, the lockManager checks some different nodes map, when it uses the node's FQN, than is later checked on line 252, where it tries to read-lock the node (and fails, because it's already locked by pessimistic locking interceptor).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBCACHE-1402) Memcached server based on JBoss Cache
by Manik Surtani (JIRA)
Memcached server based on JBoss Cache
-------------------------------------
Key: JBCACHE-1402
URL: https://jira.jboss.org/jira/browse/JBCACHE-1402
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 3.0.0.GA
This is to create a simple server daemon (similar to a TcpCacheServer) that uses memcached's binary and RESTful protocols, which proxy requests to the cache. Simply called CacheServer?
A CacheClient could also be created, which implements Cache and uses the memcached protocol to speak to CacheServer. Consistent hashing could be used to select the server picked, server topology could be piggybacked with responses back to the CacheClient.
This would allow us to:
1. Use CacheClient with memcached backends
2. Use memcached front-ends (Java, Python, Perl, C) to speak to JBoss Cache backends
3. Allow for a heterogenous mix of backends.
In future the TcpCacheServer could simply be replaced with CacheServer and the TcpCacheLoader updated to use the CacheClient.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBCACHE-1418) Expose locality of data for partitioned caches
by Manik Surtani (JIRA)
Expose locality of data for partitioned caches
----------------------------------------------
Key: JBCACHE-1418
URL: https://jira.jboss.org/jira/browse/JBCACHE-1418
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Replication
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 3.2.0
After we implement a distributed cache based on partitioning, JBCACHE-61, we should also expose a mechanism to locate data within a cluster, to help compute grid products like FishFarm (https://fishfarm.dev.java.net/) and GridGain (http://www.gridgain.org). Perhaps something like:
DataLocator dl = Cache.getDataLocator(); // return a null if not using a partitioned cache? Or a specialized DataLocator that statically assumes a fully replicated cache or a local cache depending on cache mode?
List<Address> addresses = dl.locate(myFqn); // locate single fqns. Return a list of addresses since it may exist on > 1 node
Map<Fqn, List<Address>> as = dl.locate(fqn1, fqn2, fqn3); // locate multiple fqns
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBCACHE-1409) Unnecessarily scary debug message during config parsing
by Brian Stansberry (JIRA)
Unnecessarily scary debug message during config parsing
-------------------------------------------------------
Key: JBCACHE-1409
URL: https://jira.jboss.org/jira/browse/JBCACHE-1409
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.0.GA
Reporter: Brian Stansberry
Assignee: Manik Surtani
Priority: Minor
XmlConfigurationParser.setValue logs a rather alarming message when it tries and fails to find a property setter that takes a String or Element:
2008-09-11 17:07:09,026 DEBUG [org.jboss.cache.factories.XmlConfigurationParser] (main) Unrecognised attribute SyncReplTimeout. Please check your configuration. Ignoring!!
It then goes on to look for a setter that takes a different type (in this case, long) and sets the property, or fails with an exception if there really is no appropriate setter.
It's only a DEBUG message, so this is minor, but the message itself is quite alarming. If there needs to be a message at all, perhaps "No property SyncReplTimeout of type String or Element; checking for other types."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBCACHE-1416) Allow to put jboss cache and log4j libs in the WEB-INF/lib dir. The Cache#shutdown and Cache#stop methods are not blocking an provok errors when undeploying a webapp.
by Laurent Mimoun (JIRA)
Allow to put jboss cache and log4j libs in the WEB-INF/lib dir. The Cache#shutdown and Cache#stop methods are not blocking an provok errors when undeploying a webapp.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBCACHE-1416
URL: https://jira.jboss.org/jira/browse/JBCACHE-1416
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 2.2.0.GA
Environment: tomcat6
Reporter: Laurent Mimoun
Assignee: Manik Surtani
Priority: Critical
When undeploying the webapp, here is the errors in the logs :
Sep 25, 2008 7:50:36 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive ROOT.war
Sep 25, 2008 7:55:33 PM org.apache.catalina.startup.HostConfig checkResources
INFO: Undeploying context []
Sep 25, 2008 7:55:33 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive ROOT.war
Sep 25, 2008 7:55:34 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load java.io.PrintWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1246)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1206)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:154)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193)
at org.jgroups.protocols.MPING.run(MPING.java:362)
at java.lang.Thread.run(Thread.java:619)
Sep 25, 2008 7:55:34 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.VectorWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1246)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1206)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:154)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193)
at org.jgroups.protocols.MPING.run(MPING.java:362)
at java.lang.Thread.run(Thread.java:619)
Sep 25, 2008 7:55:34 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.VectorWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1246)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1206)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:154)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193)
at org.jgroups.protocols.Discovery$PingSenderTask$1.run(Discovery.java:389)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Sep 25, 2008 7:55:36 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.VectorWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
After a closer analysis, the reason is quite simple, in the destroy method of the servlet of my webapp, the method Cache#stop is called but this method doesn't wait that the jgroups thread to finish.
So the destroy method returns but there are still jgroups thread in the jvm.
These threads sometimes use the log4j api (that is in the war too) to log message but the classloader of the webapp is no more avalaible to load the log4j classes because the webapp has been undeployed, that's why an "could not load class ...log4j" happens.
To fix the problem, I think the lifecycle methods of jboss cache must be blocking is the case of using jgroups threads.
This way the jboss cache and log4j will be able to be packaged in a single war file that is very a good thing in terms of maintenance developpement and so on.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBCACHE-1470) Option to disable cache event generation for a cache operation.
by Galder Zamarreno (JIRA)
Option to disable cache event generation for a cache operation.
---------------------------------------------------------------
Key: JBCACHE-1470
URL: https://jira.jboss.org/jira/browse/JBCACHE-1470
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 3.1.0.GA
For the prototype that I'm building for JBCACHE-816, I would like to implement a new Option that
disables generation of cache listener events for a particular cache operation.
Why is that I want to implement this? First, bear in mind that currently, I'm trying to get a prototype
done just by accessing the Cache interface (no SPI)
Take this scenario:
- Cluster 1 with nodes A, B and C.
- Cluster 2 with nodes X, Y and Z.
The idea of JBCACHE-816 is to enable inter cluster or data centre asynchronous replication of data.
This service would be a singleton running in the coordinators of the the clusters that we're interconnecting.
For this case, assume coord for C1 is A and coord for C2 is X.
Both A and X start a new JGroups communication channel to pass each other node modification or
removal messages. The service is based around cache listeners where they listen to cache
modifications notifications and send it to the other node. For example:
User puts data in A. Listener in A catches that, takes the modification and sends it over the JGroups channel
to X which in turn needs to replicate it to the C2. To do that, it currently uses Cache API, so X calls put(...) on
the cache.
I'd like to make communications be both way to give much greater flexibility to the solution, so when X calls
put(...) on the cache, it'll also receive notifications so you basically end up in an endless ping pong effect.
The idea is for this put() call not to generate event notifications locally to avoid this ping pong effect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months