September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3504) LevelDB Cache store in server doesn't keep data between restarts

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3504: -------------------------------- Fix Version/s: 6.0.0.Beta2 (was: 6.0.0.Beta1) > LevelDB Cache store in server doesn't keep data between restarts > ---------------------------------------------------------------- > > Key: ISPN-3504 > URL: https://issues.jboss.org/browse/ISPN-3504 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Tristan Tarrant > Fix For: 6.0.0.Beta2 > > > I have config with passivation="false" purge="false" > and expect data to survive restarts which doesn't happen. > {code} > <cache-container name="default" default-cache="default" > listener-executor="infinispan-listener"> > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <leveldb-store path="temp-leveldb" block-size="1024" > cache-size="50000" clear-threshold="100000" passivation="false" > purge="false" > > <expiration path="temp-leveldb-expired" queue-size="2000" /> > <compression type="SNAPPY" /> > <implementation type="JAVA" /> > </leveldb-store> > </local-cache> > <local-cache name="memcachedCache" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > </local-cache> > </cache-container> > {code} > failing test: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....; > hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798 > for JDG 6.2.0.DR4 -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3530) The HotRod client should support a separate CH for each cache

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3530: ---------------------------------- Summary: The HotRod client should support a separate CH for each cache Key: ISPN-3530 URL: https://issues.jboss.org/browse/ISPN-3530 Project: Infinispan Issue Type: Feature Request Components: Remote protocols Affects Versions: 6.0.0.Alpha4 Reporter: Dan Berindei Assignee: Galder Zamarreño Fix For: 6.0.0.Final With asymmetric clusters, each cache can have its own consistent hash, so the primary owner of a key in one cache is not necessarily the owner in all the caches. Even with a symmetric cluster, the same client may be used to access both distributed and replicated caches, and those would certainly have a different CH. In order to send the operations to the correct owner, the HotRod client should use a different CH for each cache. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3529) Add support for the segment-based CH in the HotRod protocol

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3529?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3529: ------------------------------- Issue Type: Feature Request (was: Enhancement) > Add support for the segment-based CH in the HotRod protocol > ----------------------------------------------------------- > > Key: ISPN-3529 > URL: https://issues.jboss.org/browse/ISPN-3529 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Affects Versions: 6.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: hotrod, hotrod-java-client > Fix For: 6.0.0.Final > > > The server CH changed in version 5.2 from virtual-nodes-based to segment-based, but the client CH stayed the same. The server is able to translate the server CH into a client CH, but the translation is imperfect: > 1. Sometimes the client CH computes a different primary owner than the server CH. > 2. The client CH gets slower as the number of segments increases, the server CH performance stays the same. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3529) Add support for the segment-based CH in the HotRod protocol

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3529: ---------------------------------- Summary: Add support for the segment-based CH in the HotRod protocol Key: ISPN-3529 URL: https://issues.jboss.org/browse/ISPN-3529 Project: Infinispan Issue Type: Enhancement Components: Remote protocols Affects Versions: 6.0.0.Alpha4 Reporter: Dan Berindei Assignee: Galder Zamarreño Fix For: 6.0.0.Final The server CH changed in version 5.2 from virtual-nodes-based to segment-based, but the client CH stayed the same. The server is able to translate the server CH into a client CH, but the translation is imperfect: 1. Sometimes the client CH computes a different primary owner than the server CH. 2. The client CH gets slower as the number of segments increases, the server CH performance stays the same. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3528) CacheLoaderInterceptor.visitEntrySetCommand can hang

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3528: ---------------------------------- Summary: CacheLoaderInterceptor.visitEntrySetCommand can hang Key: ISPN-3528 URL: https://issues.jboss.org/browse/ISPN-3528 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 6.0.0.Alpha4 Reporter: Dan Berindei Assignee: Mircea Markus Priority: Critical Fix For: 6.0.0.Beta2 {{PersistenceManager.processOnAllStores}} receives a {{CacheLoaderTask}} parameter and calls it on potentially many threads concurrently. So the task object must be thread-safe. The {{CacheLoaderTask}}&zwj;s used by {{CacheLoaderInterceptor.visitEntrySetCommand}}/{{visitKeySetCommand}}/{{visitValuesCommand}} are not thread-safe. They use a {{HashSet}} without any synchronization, and when accessed from concurrent threads the map can be corrupted. When this happens, the thread will block in an infinite loop: {noformat} "testng-LocalModeNoPassivationTest" prio=10 tid=0x00007f19141ac800 nid=0x622c runnable [0x00007f1902a62000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.put(HashMap.java:498) at java.util.HashSet.add(HashSet.java:217) at java.util.AbstractCollection.addAll(AbstractCollection.java:342) at org.infinispan.interceptors.CacheLoaderInterceptor.visitEntrySetCommand(CacheLoaderInterceptor.java:195) ... {noformat} -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3527) Transaction boundary commands can be completed before state transfer applies an active transaction

by Erik Salter (JIRA)

Erik Salter created ISPN-3527: --------------------------------- Summary: Transaction boundary commands can be completed before state transfer applies an active transaction Key: ISPN-3527 URL: https://issues.jboss.org/browse/ISPN-3527 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.7.Final Reporter: Erik Salter Assignee: Mircea Markus There is a condition where a transaction boundary command, like a RollbackCommand, can be processed by the new owner of a tx-encapsulated key before it applies the active transaction. On a view change: The forwarding node waits until its transactions from the new topology ID is set before issuing the command. 2013-09-17 14:28:33,725 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-350,session-resource-cluster,east-dht5-60816(CMC-Denver-CO)) Invoked with command RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:local, cacheName='eigAllocation', topologyId=-1} and InvocationContext [org.infinispan.context.impl.LocalTxInvocationContext@1f225e51] 2013-09-17 14:28:33,727 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] (OOB-350,session-resource-cluster,east-dht5-60816(CMC-Denver-CO)) handleTopologyAffectedCommand for command RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:local, cacheName='eigAllocation', topologyId=-1} 2013-09-17 14:28:33,727 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (OOB-350,session-resource-cluster,east-dht5-60816(CMC-Denver-CO)) Waiting for transaction data for topology 26, current topology is 25 ... 2013-09-17 14:28:34,101 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (OOB-350,session-resource-cluster,east-dht5-60816(CMC-Denver-CO)) east-dht5-60816(CMC-Denver-CO) broadcasting call RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:local, cacheName='eigAllocation', topologyId=26} to recipient list [west-dht4-48045(CH2-Chicago-IL), east-dht5-60816(CMC-Denver-CO), east-dht2-60243(CMC-Denver-CO)] However, the receiving node has not finished applying the transactions from the forwarding node yet for this topology ID. So the tx cannot be found, resulting in a stale tx and an unusable key. 2013-09-17 14:28:34,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-153,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) Calling perform() on RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:remote, cacheName='eigAllocation', topologyId=26} 2013-09-17 14:28:34,116 TRACE [org.infinispan.commands.tx.AbstractTransactionBoundaryCommand] (OOB-153,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) Did not find a RemoteTransaction for GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:remote 2013-09-17 14:28:34,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-153,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) About to send back response SuccessfulResponse{responseValue=null} for command RollbackCommand {gtx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:remote, cacheName='eigAllocation', topologyId=26} ... 2013-09-17 14:28:34,161 TRACE [org.infinispan.transaction.TransactionTable] (OOB-408,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) Created and registered remote transaction RemoteTransaction{modifications=[PutKeyValueCommand{key=EdgeResourceCacheKey[edgeDeviceId=4109,resourceId=16825], value=EdgeInputResource [edgeInputId=16825, currentBandwidth=0, maxBandwidth=1048576000], flags=null, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1, successful=true, ignorePreviousValue=false}], lookedUpEntries={}, lockedKeys=null, backupKeyLocks=null, missingLookedUpEntries=false, isMarkedForRollback=false, tx=GlobalTransaction:<east-dht5-60816(CMC-Denver-CO)>:48002:remote} 2013-09-17 14:28:34,733 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (OOB-408,session-resource-cluster,west-dht4-48045(CH2-Chicago-IL)) Signalling transaction data received for topology 26 -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2143) Improve how different indexed caches sync up on new indexed types

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2143?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2143: ------------------------------------- For the record, 'metadata cache store' == org.infinispan.registry.ClusterRegistry. > Improve how different indexed caches sync up on new indexed types > ----------------------------------------------------------------- > > Key: ISPN-2143 > URL: https://issues.jboss.org/browse/ISPN-2143 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Priority: Blocker > Labels: stable_embedded_query > Fix For: 6.0.0.CR1 > > > Currently when a node receives an unknown type, it doesn't inform all other nodes, which might fail to get metadata and index boot information from it. > Also, the list of known types should be stored somewhere. > When a shared index is used, we might be able to load some type names from the index itself, but unfortunately usually we need the type name to initialize the index. Rely on an index storage convention? > See also comments in {{org.infinispan.query.indexmanager.IndexUpdateCommand}} -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3526) Inject dependecies into the marshaller used for compatibility mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3526?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3526: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2081 > Inject dependecies into the marshaller used for compatibility mode > ------------------------------------------------------------------ > > Key: ISPN-3526 > URL: https://issues.jboss.org/browse/ISPN-3526 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.Beta1 > > > Interoperability between remote query and embedded mode requires a special marshaller to be specified (CompatibilityProtoStreamMarshaller) which has a dependency on the CacheManager. It should not be the user's responsibility to inject this dependency because that could only work with programmatic configuration and would be impossible with xml config. > Probably the best way to solve this is to automatically wire all user provided marshaller _instances_ if they are annotated for injection. > -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3526) Inject dependecies into the marshaller used for compatibility mode

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3526: ----------------------------------- Summary: Inject dependecies into the marshaller used for compatibility mode Key: ISPN-3526 URL: https://issues.jboss.org/browse/ISPN-3526 Project: Infinispan Issue Type: Feature Request Affects Versions: 6.0.0.Alpha4 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 6.0.0.Beta1 Interoperability between remote query and embedded mode requires a special marshaller to be specified (CompatibilityProtoStreamMarshaller) which has a dependency on the CacheManager. It should not be the user's responsibility to inject this dependency because that could only work with programmatic configuration and would be impossible with xml config. Probably the best way to solve this is to automatically wire all user provided marshaller _instances_ if they are annotated for injection. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3327) Server init.d script should be customized for Infinispan

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3327?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3327: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 983781|https://bugzilla.redhat.com/show_bug.cgi?id=983781] The grep command could be universal. Something like grep '.*started.*in.*ms' . I tried this and it worked well for all JDG, ISPN server and EAP, started with or without errors. Just a tip... > Server init.d script should be customized for Infinispan > -------------------------------------------------------- > > Key: ISPN-3327 > URL: https://issues.jboss.org/browse/ISPN-3327 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha4 > > > The current init.d script included in Infinispan Server should be appropriately renamed and verified -- 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

12 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013