[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, 1 month
[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, 1 month
[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, 1 month
[JBoss JIRA] Created: (JBCACHE-1407) Region-based marshalling to support multiple regions in a PREPARE.
by Brian Stansberry (JIRA)
Region-based marshalling to support multiple regions in a PREPARE.
------------------------------------------------------------------
Key: JBCACHE-1407
URL: https://jira.jboss.org/jira/browse/JBCACHE-1407
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Replication
Reporter: Brian Stansberry
Assignee: Manik Surtani
A transaction can operate on multiple regions within a cache, so the resulting PREPARE will include data from multiple regions. But the region-based marshalling logic will identify a single region Fqn for the message (first one it finds); result is data from other regions will not unmarshall properly.
Region-based marshalling needs to be able to handle such a case; analyze the prepare and create a separate region-fqn/data pair for each time the region changes.
Storing the node's data in an org.jboss.cache.marshall.MarshalledValue doesn't solve the problem, as in use cases like Hibernate, custom types can be part of the Fqn (below the region root.)
--
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, 2 months
[JBoss JIRA] Created: (JBCACHE-1406) issue with removing an node in tx
by Mircea Markus (JIRA)
issue with removing an node in tx
---------------------------------
Key: JBCACHE-1406
URL: https://jira.jboss.org/jira/browse/JBCACHE-1406
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP9
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 1.4.X
tx.start()'
cache.put(/a/b/c);
cache.remove(/a/b);
cache.put(/a/b/d);
tx.commit();
assert "this still exists in the internal structure" : cache.peek(/a/b/c) == null;
above assertion fails.
The problem is that when tx commits and cache wants to remove /a/b, sees that its not marked for removal (as it was re-added through put(/a/b/d) )and does not look in its children.
Method is TreeCache.realRemove, and it;s called from TxInterceptor.commit()
UT added to reproduce the issue is: org.jboss.cache.RemoveOnTxTest.
--
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, 3 months
[JBoss JIRA] Created: (JBCACHE-1412) TreeCacheMarshaller140 marshalling replaces distinct but equal() objects
by Brian Stansberry (JIRA)
TreeCacheMarshaller140 marshalling replaces distinct but equal() objects
------------------------------------------------------------------------
Key: JBCACHE-1412
URL: https://jira.jboss.org/jira/browse/JBCACHE-1412
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Replication
Affects Versions: 1.4.1.SP9
Reporter: Brian Stansberry
Assignee: Manik Surtani
Priority: Critical
The marshalling logic in TreeCacheMarshaller140 uses a HashMap as store of objects already written so it can replace subsequent writes of the same object with a magic number. Use of a HashMap is incorrect, as magic number replacement should only occur if an object with the same identity is detected, not one that just satisfies equals() but not ==.
Either a custom map that uses System.identityHashCode() for hashing and == instead of equals() for equality is needed, or the map key should be System.identityHashCode(). Note the Object.hashCode() javadocs do not absolutely guarantee uniqueness in System.identityHashCode(), so a custom map is probably better:
"As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)"
Non-uniquenesss in System.identityHashCode() might be more of an issue in systems with large heaps that can't be addressed with 32 bits.
--
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, 3 months
[JBoss JIRA] Created: (JBCACHE-1408) Optimistic locking + JDBC cache loader + DataSources
by Mircea Markus (JIRA)
Optimistic locking + JDBC cache loader + DataSources
----------------------------------------------------
Key: JBCACHE-1408
URL: https://jira.jboss.org/jira/browse/JBCACHE-1408
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.0.0.ALPHA1, 2.2.0.GA
Reporter: Mircea Markus
Assignee: Manik Surtani
CacheStoreInterceptor.handleCommitCommand calls CacheStoreInterceptor.storeInternalState.
In the optimistic scenario, this will try to add the version of the node (internal state) to the previously stored nodes (nodes are being called in handlePrepareCommand).
The problem is that handleCommitCommand is called in an transaction having the status Status.COMMITTED, and when trying to fetch a Connection, org.jboss.resource.connectionmanager.TxConnectionManager checks for current tx status and throws an exception if running tx is not active.
Solution: move the code which stores additional info in handlePrepareCommand. This should also bring important performance gains, as for each node a new DB call is made in order to add the version (see CacheStoreInterceptor.storeInternalState).
--
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, 6 months