March 2009 - jbosscache-issues - Jboss List Archives

[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, 2 months

1
4
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1098) Provide a distributed locking mechanism as an option

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1098?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1098. ------------------------------------ Fix Version/s: (was: 3.2.0.GA) Resolution: Won't Fix > Provide a distributed locking mechanism as an option > ---------------------------------------------------- > > Key: JBCACHE-1098 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1098 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Manik Surtani > Assignee: Manik Surtani > > Inefficient and not scalable, but people have asked for it for very specific use cases. -- 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

1
0
0 / 0

[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, 2 months

1
2
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-67) JCache JSR-107 implementation

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-67?page=com.atlassian.jira.plu... ] Manik Surtani resolved JBCACHE-67. ---------------------------------- Fix Version/s: (was: 3.2.0.GA) Resolution: Out of Date > JCache JSR-107 implementation > ----------------------------- > > Key: JBCACHE-67 > URL: https://jira.jboss.org/jira/browse/JBCACHE-67 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Manik Surtani > -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-471) Handle JGroups MERGE

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-471?page=com.atlassian.jira.pl... ] Manik Surtani resolved JBCACHE-471. ----------------------------------- Fix Version/s: (was: 3.2.0.GA) Resolution: Out of Date > Handle JGroups MERGE > -------------------- > > Key: JBCACHE-471 > URL: https://jira.jboss.org/jira/browse/JBCACHE-471 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4 > Reporter: Manik Surtani > Assignee: Manik Surtani > > When JGroups needs to do a merge due to a temporary break in the group structure, JGroups does not handle the merging of data. This is usually left up to the application to handle. > JBossCache should support pluggable merge policies, we could provide some simple merge policies and allow users to write their own. > 1. Evict on merge policy - when a merge occurs, evict the entire in-memory state. Useful for Hibernate or when used with a shared cache loader. > 2. Other merge algos ... ? -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1233) Use XStream to serialize user classes as an option, to allow for replication between different versions of the app

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1233?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1233. ------------------------------------ Fix Version/s: (was: 3.2.0.GA) Resolution: Won't Fix > Use XStream to serialize user classes as an option, to allow for replication between different versions of the app > ------------------------------------------------------------------------------------------------------------------ > > Key: JBCACHE-1233 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1233 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.1.0.CR2 > Reporter: Manik Surtani > Assignee: Manik Surtani > > Deserialization failures (class definitions being changed) could be handled by re-playing the call, this time serializing using XStream which is more resilient to class definition changes. Perhaps a cfg option when the user is aware that class definitions have changed? -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1336) Pooling Object Streams

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1336?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1336. ------------------------------------ Fix Version/s: (was: 3.2.0.GA) Resolution: Won't Fix > Pooling Object Streams > ---------------------- > > Key: JBCACHE-1336 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1336 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mircea Markus > Assignee: Manik Surtani > > ObjectStreams creation consumes a lot of time when it comes to marshalling commands (e.g. > 5% of total command in case of put is in building the ObjectStream). > Pooling them would be an important performance enhancement. > We cannot pool the ones from JDK as these cache .class information which results in memory leakage. > Investigate the possibility of implementing own alternative ObjectStreams which would be pool-able. -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1394) Refactor transaction logic

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1394?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1394. ------------------------------------ Fix Version/s: (was: 3.1.0.GA) Resolution: Won't Fix > Refactor transaction logic > -------------------------- > > Key: JBCACHE-1394 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1394 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transactions > Reporter: Manik Surtani > Assignee: Mircea Markus > Original Estimate: 3 days > Remaining Estimate: 3 days > > There are some redundancies here, which need tidying up. Specifically: > 1. Redundant behaviour between TxInterceptor and InvocationContextInterceptor. ICI should *just* be in change of setting up and clearing down contexts. TxI should start implicit txs if needed, register syncs, handle remote prepares, commits and rollbacks, etc. > 2. InvocationContext and TransactionContext has some redundanceis which can be cleaned up and optimised. > 3. TransactionTable has an unnecessary number of Maps - these can be improved. It basically needs to be able to look up a Transaction and TransactionContext given a GlobalTransaction (for remote transactions coming in), as well as look up a GlobalTransaction and a TransactionContext given a Transaction (local transactions, retrieved from the TransactionManager). > It is probably best to wait for Optimistic and Pessimistic Locking to be removed before this since a lot of this is legacy support code. -- 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

1
0
0 / 0

[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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1487) Node count fails when Cache.toString() called between @Inject and @Start methods.

by Galder Zamarreno (JIRA)

Node count fails when Cache.toString() called between @Inject and @Start methods. --------------------------------------------------------------------------------- Key: JBCACHE-1487 URL: https://jira.jboss.org/jira/browse/JBCACHE-1487 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.3.GA Reporter: Galder Zamarreno Assignee: Manik Surtani Node count fails when Cache bean is deployed via MC and TRACE is enabled on org.jboss.kernel: 2009-03-03 21:40:51,505 ERROR [AbstractKernelController] (main) Error installing to Instantiated: name=CacheClusterA1 state=Described java.lang.UnsupportedOperationException: Not supported in UnversionedNode at org.jboss.cache.AbstractNode.getChildrenDirect(AbstractNode.java:277) at org.jboss.cache.mvcc.NodeReference.getChildrenDirect(NodeReference.java:272) at org.jboss.cache.invocation.NodeInvocationDelegate.getChildrenDirect(NodeInvocationDelegate.java:163) at org.jboss.cache.DataContainerImpl.numNodes(DataContainerImpl.java:461) at org.jboss.cache.DataContainerImpl.getNumberOfNodes(DataContainerImpl.java:438) at org.jboss.cache.DataContainerImpl.toString(DataContainerImpl.java:394) at org.jboss.cache.DataContainerImpl.toString(DataContainerImpl.java:372) at org.jboss.cache.invocation.CacheInvocationDelegate.toString(CacheInvocationDelegate.java:144) at java.lang.String.valueOf(String.java:2615) at org.jboss.util.JBossStringBuilder.append(JBossStringBuilder.java:114) at org.jboss.dependency.plugins.AbstractControllerContext.toString(AbstractControllerContext.java:362) MC is printing the cache content in between the two calls to DataContainerImpl.createRootNode(). First call happens during the @Inject phase and at that point, DataContainerImpl's config has not been set yet so, getting node numbers is called with usingMvcc=false. This leads to getChildrenDirect() being called on the root node and this call fails. See attached logs to compare deployment when TRACE is enabled versus deployment when DEBUG is enabled. -- 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

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues March 2009