September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-469) Native Hot Rod client for .NET

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-469?page=com.atlassian.jira.plugin.s... ] Mircea Markus resolved ISPN-469. -------------------------------- Resolution: Done tracked here: https://issues.jboss.org/browse/HRCPP > Native Hot Rod client for .NET > ------------------------------ > > Key: ISPN-469 > URL: https://issues.jboss.org/browse/ISPN-469 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Environment: Must run .NET versions 4, 4.5 > Optional: .NET versions 3, 3.5 > Reporter: Manik Surtani > Assignee: Mircea Markus > Labels: jdg62 > Fix For: 6.0.0.Beta2, 6.0.0.CR1 > > > .NET client impl for HotRod. Protocol is documented here: > http://community.jboss.org/wiki/HotRodProtocol > Could be based off the Java reference impl client: > https://github.com/infinispan/infinispan/tree/master/client/hotrod-client -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2034) Add backwards serialization compatibility tests

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2034?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2034: -------------------------------- Fix Version/s: 6.1.0.Final (was: 6.0.0.CR1) > Add backwards serialization compatibility tests > ----------------------------------------------- > > Key: ISPN-2034 > URL: https://issues.jboss.org/browse/ISPN-2034 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: compatibility > Fix For: 6.1.0.Final > > > Take each existing minor branch, i.e. 4.1.x, 4.0.x,...etc and modify VersionAwareMarshallerTest so that payloads are stored in a data file. > Then, take data files for each branch and store in git (master and 5.1.x), and try reading them with the existing externalizer/marshalling set up. > It should work... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3348) Unable to read entries from SingleFileCacheStore after server restart

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3348?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3348: -------------------------------- Assignee: Mircea Markus (was: Galder Zamarreño) > Unable to read entries from SingleFileCacheStore after server restart > --------------------------------------------------------------------- > > Key: ISPN-3348 > URL: https://issues.jboss.org/browse/ISPN-3348 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Alpha1 > Reporter: Martin Gencur > Assignee: Mircea Markus > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > > Using the following configuration: > {code:xml} > <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="default"> > <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue"> > <local-cache name="default" start="EAGER"> > <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/> > <transaction mode="NONE"/> > <store class="org.infinispan.loaders.file.SingleFileCacheStore" passivation="false" preload="false" purge="false"> > <property name="location">${java.io.tmpdir}/single-file-cache-store</property> > <property name="maxEntries">2</property> > </store> > </local-cache> > </cache-container> > </subsystem> > {code} > ...it is not possible to retrieve the cache entry from the cache store after server restart, as demonstrated by the following test: > {code:java} > RemoteCache<String, String> rc = rcm.getCache(); > rc.clear(); > assertNull(rc.get("k1")); > rc.put("k1", "v1"); > rc.put("k2", "v2"); > rc.put("k3", "v3"); > assertEquals("v1", rc.get("k1")); > assertEquals("v2", rc.get("k2")); > assertEquals("v3", rc.get("k3")); > controller.kill(CONTAINER); > controller.start(CONTAINER); > assertEquals("v2", rc.get("k2")); > //^^^fails here - unable to find k2 > assertEquals("v3", rc.get("k3")); > assertNull(rc.get("k1")); //maxEntries was 2, this entry should be lost as the oldest entries are removed > controller.stop(CONTAINER); > {code} > Note that preload is set to false for this test. When I set it to true, the test passes. > I tried to modify BaseCacheStoreFunctionalTest#testPreloadAndExpiry, disable "preload" and retrieve the cache entries after server restart by calling cache.get() (not from DataContainer) and the test passed (I ran SingleFileCacheStoreFunctionalTest which extends BaseCacheStoreFunctionalTest). So it seems the bug is related to the server distribution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2034) Add backwards serialization compatibility tests

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2034?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2034: -------------------------------- Fix Version/s: (was: 6.0.0.Beta2) > Add backwards serialization compatibility tests > ----------------------------------------------- > > Key: ISPN-2034 > URL: https://issues.jboss.org/browse/ISPN-2034 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: compatibility > Fix For: 6.0.0.CR1 > > > Take each existing minor branch, i.e. 4.1.x, 4.0.x,...etc and modify VersionAwareMarshallerTest so that payloads are stored in a data file. > Then, take data files for each branch and store in git (master and 5.1.x), and try reading them with the existing externalizer/marshalling set up. > It should work... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2638) Supporting rolling upgrades of a live Memcached cluster

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2638?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-2638. --------------------------------- Resolution: Won't Fix memchached are used for caching temporary data, rolling upgrade for such a system is not required. > Supporting rolling upgrades of a live Memcached cluster > ------------------------------------------------------- > > Key: ISPN-2638 > URL: https://issues.jboss.org/browse/ISPN-2638 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Galder Zamarreño > Labels: jdg62 > Fix For: 6.0.0.Beta2, 6.0.0.CR1 > > > Similar to ISPN-1410, but for Memcached clusters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3398) Unmarshall problem in compatibility mode

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3398?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3398: -------------------------------- Assignee: Pedro Ruivo (was: Galder Zamarreño) > Unmarshall problem in compatibility mode > ---------------------------------------- > > Key: ISPN-3398 > URL: https://issues.jboss.org/browse/ISPN-3398 > Project: Infinispan > Issue Type: Bug > Components: Marshalling, Remote protocols, Server > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Michal Linhard > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2, 6.0.0.Final > > > JDG 6.2.0.DR2 client/server tests using hotrod and cache in compatibility mode: > throw this: > {code} > 04:48:28,445 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-0) ISPN000136: Execution error: java.io.IOException: Unsupported protocol version 9 > at org.jboss.marshalling.river.RiverUnmarshaller.start(RiverUnmarshaller.java:1243) > at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.startObjectInput(AbstractJBossMarshaller.java:138) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:119) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:83) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.server.hotrod.HotRodTypeConverter.unmarshall(HotRodTypeConverter.scala:36) [infinispan-server-hotrod-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.server.hotrod.HotRodTypeConverter.boxValue(HotRodTypeConverter.scala:22) [infinispan-server-hotrod-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitPutKeyValueCommand(TypeConverterInterceptor.java:72) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:46) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:169) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} > the exception appears for each request, the form is always > "Unsupported protocol version X" where X differs > see > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/PERF-CS/jo... > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/PERF-CS/jo... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3541) Purge is not working for file-store

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3541?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3541: -------------------------------- Fix Version/s: 6.0.0.Beta2 > Purge is not working for file-store > ----------------------------------- > > Key: ISPN-3541 > URL: https://issues.jboss.org/browse/ISPN-3541 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Beta1 > Reporter: Jakub Markos > Assignee: Mircea Markus > Fix For: 6.0.0.Beta2 > > > When using this configuration (notice the purge=true) > {code:xml} > <local-cache name="default" start="EAGER" batching="false"> > <file-store name="hello" > passivation="true" > relative-to="temp" > path="${cachestore.name}" > purge="true"/> > </local-cache> > {code} > and running this test > {code} > for (int i = 0; i < 3; i++) { > cache.put("k" + i, i); > } > controller.stop(CONTAINER); // stops the server > controller.start(CONTAINER); > for (int i = 0; i < 3; i++) { > System.out.println("k" + i + ": " + cache.get("k" + i)); > } > {code} > the entries can be read even after server restart: > {quote} > k0: 0 // expecting null here > k1: 1 // expecting null here > k2: 2 // expecting null here > {quote} > Worked fine with DR4, not with ER1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1985) Calling containsValue() in a storeAsBinary cache should result in value being unmarshalled

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1985?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-1985. --------------------------------- Resolution: Rejected storeAsBinary always keep the raw version of data starting with 6.0.0.Beta2. > Calling containsValue() in a storeAsBinary cache should result in value being unmarshalled > ------------------------------------------------------------------------------------------ > > Key: ISPN-1985 > URL: https://issues.jboss.org/browse/ISPN-1985 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Manik Surtani > Priority: Minor > Fix For: 6.0.0.CR1 > > > I'm not sure this is how it works, but just adding it just in case. It can always be closed if necessary. > This is related to https://hibernate.onjira.com/browse/HHH-7256. > Does calling containsKey() is a storeAsBinary=true cache result in unmarshalling the value? > Of course, it's gonna need to unmarshall the key to be compare it, but it should not try to unmarshall the value, since this operation is different to a get(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2255) FineGrainedAtomicMap missing key, value pairs in some cluster nodes in distributed mode, embedded infinispan cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2255?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2255: -------------------------------- Fix Version/s: 6.1.0.Final (was: 6.0.0.CR1) > FineGrainedAtomicMap missing key,value pairs in some cluster nodes in distributed mode, embedded infinispan cache > ----------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2255 > URL: https://issues.jboss.org/browse/ISPN-2255 > Project: Infinispan > Issue Type: Bug > Components: Fine-grained API > Affects Versions: 5.1.5.FINAL > Environment: Details about cluster: > 1. Infinispan 5.1.5 > 2. java 7u5 64bit > 3. linux 64bit (two nodes debian and one node ubuntu) > 4. tomcat 7.0.28 > 5. jbossTM 4.16.0 JTA only > Tomcat integration code is here: > https://github.com/zvrablik/tomcatInfinispanSessionManager/tree/master/to... > 6. all machines are on real hw ( no virtual machines), date and time is synchronized and shouldn't vary more than 1 second > Reporter: Zdenek Henek > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 6.1.0.Final > > Attachments: fgamissueTest2.zip, jgroupsConfig.xml, sessionInfinispanConfigtestLB.xml > > > I am using FineGrainedAtomicMap to store data into clustering distributed cache. When clustering set to replicated doesn't cause any issues or at least I haven't run > into any. When I switch to distributed mode I don't see some key,value pairs in some nodes. This happens randomly. The numOwners is set to two and I have cluster of three nodes. > more details: > https://community.jboss.org/thread/203420?tstart=60 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2240: -------------------------------- Fix Version/s: 6.1.0.Final (was: 6.0.0.CR1) > Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key > ---------------------------------------------------------------------------------------------- > > Key: ISPN-2240 > URL: https://issues.jboss.org/browse/ISPN-2240 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.1.6.FINAL, 5.1.x > Reporter: Robert Stupp > Assignee: Mircea Markus > Priority: Critical > Fix For: 6.1.0.Final > > Attachments: ISPN-2240_fix_TimeoutExceptions.patch, somehow.zip > > > Hi, > I've encountered a lot of TimeoutExceptions just running a load test against an infinispan cluster. > I tracked down the reason and found out, that the code in org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer#releaseLock() causes these superfluous TimeoutExceptions. > A small test case (which just prints out timeouts, too late timeouts and "paints" a lot of dots to the console - more dots/second on the console means better throughput ;-) > In a short test I extended the class ReentrantPerEntryLockContainer and changed the implementation of releaseLock() as follows: > {noformat} > public void releaseLock(Object lockOwner, Object key) { > ReentrantLock l = locks.get(key); > if (l != null) { > if (!l.isHeldByCurrentThread()) > throw new IllegalStateException("Lock for [" + key + "] not held by current thread " + Thread.currentThread()); > while (l.isHeldByCurrentThread()) > unlock(l, lockOwner); > if (!l.hasQueuedThreads()) > locks.remove(key); > } > else > throw new IllegalStateException("No lock for [" + key + ']'); > } > {noformat} > The main improvement is that locks are not removed from the concurrent map as long as other threads are waiting on that lock. > If the lock is removed from the map while other threads are waiting for it, they may run into timeouts and force TimeoutExceptions to the client. > The above methods "paints more dots per second" - means: it gives a better throughput for concurrent accesses to the same key. > The re-implemented method should also fix some replication timeout exceptions. > Please, please add this to 5.1.7, if possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013