May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3091) Non-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3091?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3091: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Non-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3091 > URL: https://issues.jboss.org/browse/ISPN-3091 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > The backups do not receive the command at all. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3091) No-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3091?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3091: -------------------------------- Summary: No-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) (was: Not transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)) > No-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3091 > URL: https://issues.jboss.org/browse/ISPN-3091 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > The backups do not receive the command at all. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3091) Non-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3091?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3091: -------------------------------- Summary: Non-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) (was: No-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode)) > Non-transactional Cache.putAll or Cache.putAllAsync on primary owner is not replicated to backup owners when supportsConcurrentUpdates == true (DIST mode) > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3091 > URL: https://issues.jboss.org/browse/ISPN-3091 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > The backups do not receive the command at all. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2995) AtomicHashMap locking issue [optimistic]

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2995?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-2995: ------------------------------------ This is odd, I would have thought AtomicHashMap would only acquire a lock on the parent key and only FineGrainedAtomicHashMap would acquire locks on all the composite keys. Are you sure ApplyDeltaCommand is used for AtomicHashMap? For FGAHM, it would be nice to use grouping to keep the composite keys on the same node as the parent key (but then we'd have to enable grouping all the time, and I'm not sure if that's an option). > AtomicHashMap locking issue [optimistic] > ---------------------------------------- > > Key: ISPN-2995 > URL: https://issues.jboss.org/browse/ISPN-2995 > Project: Infinispan > Issue Type: Bug > Components: Fine-grained API > Affects Versions: 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: atomic_map, locking > Fix For: 5.3.0.Beta2 > > > In OptimisticLockingInterceptor, we are collecting the composite keys from ApplyDeltaCommand is the key belongs to the node: > {code} > case ApplyDeltaCommand.COMMAND_ID: > ApplyDeltaCommand command = (ApplyDeltaCommand) wc; > if (cdl.localNodeIsOwner(command.getKey())) { > Object[] compositeKeys = command.getCompositeKeys(); > set.addAll(Arrays.asList(compositeKeys)); > } > break; > {code} > However, when we are going to acquire the lock in the node if it is the primary owner: > {code} > protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long lockTimeout, boolean skipLocking) throws InterruptedException { > if (cdl.localNodeIsPrimaryOwner(key)) { > lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking); > } else if (cdl.localNodeIsOwner(key)) { > ctx.getCacheTransaction().addBackupLockForKey(key); > } > } > {code} > The CompositeKey should always acquire the lock. > This is probably a bug. Add an unit test to verify that locking works as expected for AtomicHashMap. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2281) Enable inter server endpoint communication in a compatibility mode

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2281?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2281: -------------------------------- Fix Version/s: 5.3.0.Beta2 5.3.0.Beta1 > Enable inter server endpoint communication in a compatibility mode > ------------------------------------------------------------------ > > Key: ISPN-2281 > URL: https://issues.jboss.org/browse/ISPN-2281 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.Beta1, 5.3.0.Beta2, 5.3.0.Final > > > Enable a compatibility mode that allows 3 main servers (Hot Rod, Memcached, REST ) and embedded mode (in-VM) to interact with each other. This would require some compatibility mode. > Obviously, this needs to be testable, so possibly adding tests to the 'integration-tests' module. Need to demonstrate storing data in one “client” and accessing from others, modifying in others, and re-accessing in the first. Test should cover each of the 4 “clients” as the initial creator. > When running in this mode, keys to be stored as Strings. In the case of REST and memcached, keys are strings anyway. In the case of Hot Rod, start the server with a flag to determine the encoding used (assuming the HR client uses Strings as well). > For values - polymorphism between a MarshalledValue (in-VM), MemcachedValue, HotRodValue, RESTValue. Lazily convert from one to the other. May need a PortableValue as well, which contains all of the metadata of all of the value types above. > May need to provide and encoding for values as well - to be able to make sense between Hot Rod byte array values and Strings in REST/memcached (base64?). > In-VM may need registration of an Externalizer? -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2637) Supporting rolling upgrades of a live REST cluster

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2637?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2637: -------------------------------- Fix Version/s: 6.0.0.Alpha3 (was: 6.0.0.Beta1) > Supporting rolling upgrades of a live REST cluster > --------------------------------------------------- > > Key: ISPN-2637 > URL: https://issues.jboss.org/browse/ISPN-2637 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Labels: rolling_upgrade > Fix For: 6.0.0.Alpha3, 6.0.0.Final > > > Similar to ISPN-1410, but for REST 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2342: -------------------------------- Fix Version/s: 6.0.0.Beta2 6.0.0.Final (was: 5.3.0.Final) > The x-site implementation needs an inter-site state transfer mechanism > ---------------------------------------------------------------------- > > Key: ISPN-2342 > URL: https://issues.jboss.org/browse/ISPN-2342 > Project: Infinispan > Issue Type: Feature Request > Components: Cross-Site Replication > Reporter: Erik Salter > Assignee: Erik Salter > Fix For: 6.0.0.Beta2, 6.0.0.Final > > > To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys. > Note that initially, this should a manual process that is invoked on one site to one of its configured backups. > This should be based on the non-blocking state transfer mechanism for consistency. > The pseudo-design may look similar to the following: > - Manually invokable, background thread > - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner. > - Iterate through the key set. > - If the key has already been modified since the process started, discard. > - Else synchronously write the key value in a TX context -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-470: ------------------------------- Fix Version/s: 6.0.0.Alpha2 (was: 6.0.0.Alpha1) > Native Hot Rod client for C++ > ----------------------------- > > Key: ISPN-470 > URL: https://issues.jboss.org/browse/ISPN-470 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Environment: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit, RHEL 5, 64-bit > Reporter: Manik Surtani > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > C++ 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-470: ------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: 6.0.0.Alpha2) > Native Hot Rod client for C++ > ----------------------------- > > Key: ISPN-470 > URL: https://issues.jboss.org/browse/ISPN-470 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Environment: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit, RHEL 5, 64-bit > Reporter: Manik Surtani > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > C++ 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2637) Supporting rolling upgrades of a live REST cluster

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2637?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2637: -------------------------------- Fix Version/s: 6.0.0.Beta1 (was: 5.3.0.Final) > Supporting rolling upgrades of a live REST cluster > --------------------------------------------------- > > Key: ISPN-2637 > URL: https://issues.jboss.org/browse/ISPN-2637 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Labels: rolling_upgrade > Fix For: 6.0.0.Beta1 > > > Similar to ISPN-1410, but for REST 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, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013