[JBoss JIRA] (ISPN-4443) Key Transformer cannot be registered early enough
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4443?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4443:
-------------------------------------
Assignee: (was: Mircea Markus)
> Key Transformer cannot be registered early enough
> -------------------------------------------------
>
> Key: ISPN-4443
> URL: https://issues.jboss.org/browse/ISPN-4443
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.2.Final
> Reporter: Rich DiCroce
>
> I have a replicated mode cache that has an index stored on each node using the RAM directory provider. I can't annotate the key class with @Transformable, so I'm using SearchManagerImplementor#registerKeyTransformer() instead. When the second node starts up, I get the below exception for about 50 milliseconds because the first node is putting stuff in the cache, and the cache has been started on the second node, but the Transformer hasn't been registered yet.
> As far as I can tell, this is a catch-22 that is impossible to avoid. I have to obtain a Cache in order to register the Transformer, but getting the cache causes the cache to be started before I can register the Transformer. The exceptions stop after the Transformer is registered, but I don't know what the state of the index is relative to the contents of the cache. My application will have a serious problem if an entry is in the cache but not the index.
> This problem is similar to ISPN-2575, but not the same.
> {code}
> 2014-06-25 17:51:48,601 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-0) ISPN000136: Execution error: java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class com.sgi.song.common.message.SONGv1.address.EndpointAddress. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer
> at org.infinispan.query.backend.KeyTransformationHandler.keyToString(KeyTransformationHandler.java:153)
> at org.infinispan.query.backend.QueryInterceptor.keyToString(QueryInterceptor.java:332)
> at org.infinispan.query.backend.QueryInterceptor.updateIndexes(QueryInterceptor.java:221)
> at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:518)
> at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:164)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:111)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:186)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:206)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:141)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.statetransfer.StateConsumerImpl.doApplyState(StateConsumerImpl.java:543)
> at org.infinispan.statetransfer.StateConsumerImpl.applyState(StateConsumerImpl.java:495)
> at org.infinispan.statetransfer.StateResponseCommand.perform(StateResponseCommand.java:62)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50)
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:172)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Unknown Source) [rt.jar:1.8.0_05]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4777) Replace command not atomic in REPL_SYNC cache mode
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4777?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4777:
-------------------------------------
Assignee: (was: Mircea Markus)
> Replace command not atomic in REPL_SYNC cache mode
> --------------------------------------------------
>
> Key: ISPN-4777
> URL: https://issues.jboss.org/browse/ISPN-4777
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Reporter: Anuj Shah
> Attachments: ReaderLockerTest.java
>
>
> This problem was discovered using the Lucene InfinispanDirectory with DistributedSegmentReadLocker. We found after a while of production usage that some Lucene files were randomly removed from the caches, but remained in the file listing entry, which resulted in an unusable index.
> We managed to replicate the problem in a test that acquires and releases read lock concurrently and checks for file deletion. We found this fails quickly when using REPL_SYNC mode, but runs for a while with DIST_SYNC.
> Some extra logging indicated that the replace command used to increment the lock counter across multiple cluster members, results in an single increment when called concurrently, with both calls reporting success. This eventually causes the file deletion, as we have now mis-counted the number of readers. We also observed the opposite effect of the counter only decrementing by one when releasing.
> Our conclusion is that the replace command fails atomicity when in REPL_SYNC mode, but works in other modes, we tried DIST_SYNC, DIST_ASYNC and REPL_ASYNC.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3882) Recovery documentation is incorrect
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3882?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3882:
-------------------------------------
Assignee: (was: Mircea Markus)
> Recovery documentation is incorrect
> -----------------------------------
>
> Key: ISPN-3882
> URL: https://issues.jboss.org/browse/ISPN-3882
> Project: Infinispan
> Issue Type: Feature Request
> Components: Documentation-Core
> Reporter: Mircea Markus
>
> <snip>
> 3.5. Cache Loaders and transactional caches
> When a cache is transactional and a cache loader is present, the cache loader won’t be enlisted in the transaction in which the cache is part. That means that it is possible to have inconsistencies at cache loader level: the transaction to succeed applying the in-memory state but (partially) fail applying the changes to the store. Manual recovery would not work with caches stores.
> </snip>
> The manual recovery should work with cache stores as well. A test - if missing - needs to be added to confirm this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3386) Cancel Map/Reduce tasks before they cause OOM errors
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3386?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3386:
-------------------------------------
Assignee: (was: Mircea Markus)
> Cancel Map/Reduce tasks before they cause OOM errors
> ----------------------------------------------------
>
> Key: ISPN-3386
> URL: https://issues.jboss.org/browse/ISPN-3386
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.3.0.Final
> Reporter: Alan Field
>
> Currently, a MapReduceTask that generates an OutOfMemory error will break a clustered cache. The node where the OOM occurs will generate SuspectExceptions on the other nodes in the cluster.
> In order to avoid this situation, Infinispan should monitor free memory and cancel the MapReduceTask if free memory is below a user definable threshold. [~pruivo] has also suggested allowing the API user to set the priority of tasks, so that the Map Reduce Manager can cancel lower priority tasks first. This functional could also be included with ISPN-2991.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4553) Add possibility to enable/disable jmx statistics on cache level using RHQ
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4553?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4553:
-------------------------------------
Assignee: (was: Mircea Markus)
> Add possibility to enable/disable jmx statistics on cache level using RHQ
> -------------------------------------------------------------------------
>
> Key: ISPN-4553
> URL: https://issues.jboss.org/browse/ISPN-4553
> Project: Infinispan
> Issue Type: Feature Request
> Components: JMX, reporting and management
> Affects Versions: 7.0.0.Alpha5
> Reporter: Tomas Sykora
> Labels: rhq
>
> Monitoring of cache statistics (InVM plugin for RHQ) works pretty well now. However, when we create a brand new cache (using mgmt operation an a cache manager) -- this new cache is configured with DISABLED jmx stats by default.
> It would be awesome to add operation which can dynamically enable and disable JMX statistics per request (e.g. issue another JMX operation on a cache level.)
> Please, comment whether is this even possible and we will be not violating any restriction. WDYT? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3575) Can not create newCache from baseCache from which to get the configuration inside EAP server
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3575?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3575:
-------------------------------------
Assignee: (was: Mircea Markus)
> Can not create newCache from baseCache from which to get the configuration inside EAP server
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-3575
> URL: https://issues.jboss.org/browse/ISPN-3575
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 6.0.0.Beta1
> Reporter: Vitalii Chepeliuk
> Attachments: jboss-as-carmart-tx.war
>
>
> After deploying carmart-tx application on EAP server and running create command with like paramer, ISPN019016 error occurs
> [remoting://localhost:9999/DefaultCacheManager/]> create newCache like carcache
> ISPN019016: No such cache: 'carcache'
> [remoting://localhost:9999/DefaultCacheManager/]> cache
> ___defaultcache carcache
> [remoting://localhost:9999/DefaultCacheManager/]> cache carcache
> [remoting://localhost:9999/DefaultCacheManager/carcache]> create newCache like carcache
> ISPN019016: No such cache: 'carcache'
> [remoting://localhost:9999/DefaultCacheManager/carcache]> create newCache like carcache
> ISPN019016: No such cache: 'carcache'
> [remoting://localhost:9999/DefaultCacheManager/carcache]> cache carcache
> [remoting://localhost:9999/DefaultCacheManager/carcache]> get carnumbers
> {"java.util.ArrayList":["FML 23-25","1P3 2632","1B2 1111","6T4 2526","2B2 4946"]}
> [remoting://localhost:9999/DefaultCacheManager/carcache]> get "6T4+2526"
> {"org.jboss.as.quickstarts.datagrid.carmart.model.Car":{"brand":"Mazda MX-5","displacement":1.8,"type":"CABRIO","color":"red","numberPlate":"6T4 2526","country":"USA"}}
> [remoting://localhost:9999/DefaultCacheManager/carcache]> create newCache like carcache
> ISPN019016: No such cache: 'carcache'
> [remoting://localhost:9999/DefaultCacheManager/carcache]> cache newCache
> ISPN019016: No such cache: 'newCache'
> [remoting://localhost:9999/DefaultCacheManager/carcache]> cache
> ___defaultcache carcache
> [remoting://localhost:9999/DefaultCacheManager/carcache]> cache ___defaultcache
> [remoting://localhost:9999/DefaultCacheManager/___defaultcache]> cache
> ___defaultcache
> [remoting://localhost:9999/DefaultCacheManager/___defaultcache]> create newCache like ___defaultcache
> ISPN019016: No such cache: '___defaultcache'
> -------------------------------------------------------------------------------------------------------
> Here is stack trace from server
> 13:47:00,970 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.IllegalArgumentException: ISPN019016: No such cache: 'carcache'
> at org.infinispan.cli.interpreter.session.SessionImpl.createCache(SessionImpl.java:93) [infinispan-cli-server-6.0.0.Beta1.jar:6.0.0.Beta1]
> at org.infinispan.cli.interpreter.statement.CreateStatement.execute(CreateStatement.java:25) [infinispan-cli-server-6.0.0.Beta1.jar:6.0.0.Beta1]
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:150) [infinispan-cli-server-6.0.0.Beta1.jar:6.0.0.Beta1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271) [infinispan-core-6.0.0.Beta1.jar:6.0.0.Beta1]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_25]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) [rt.jar:1.7.0_25]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1475)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:952)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$2.run(ServerInterceptorFactory.java:100)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$2.run(ServerInterceptorFactory.java:96)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_25]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:96)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 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]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3749) Revisit JGroups Configuration files
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3749?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3749:
-------------------------------------
Assignee: (was: Mircea Markus)
> Revisit JGroups Configuration files
> -----------------------------------
>
> Key: ISPN-3749
> URL: https://issues.jboss.org/browse/ISPN-3749
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 6.0.0.Final
> Reporter: William Burns
>
> Bela mentioned that currently our *-tcp.xml files have UFC defined in them. He no longer has that in his default configuration. We should revisit our configuration files to make sure they are as closely aligned to JGroups as we can.
> {quote}
> <bela_> I was looking at infinispan master and noticed that the *-tcp.xml configs still have UFC in them
> <bela_> This is not something I have in the default configs in JGroups...
> <bela_> perhaps this should be changed...
> <bela_> pferraro: dberindei wburns ^^^
> * rachmatowicz has quit (Quit: Ex-Chat)
> <wburns> bela_ I can't say I know why it is still there, other than it has been there for a while
> <bela_> ok, perhaps someone can take a look ? The closer the Infinispan configs are to the JGroups configs, the better
> <pferraro> bela_: WF's tcp stack does not have UFC
> <bela_> ok, good. But Infinispan does have it
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months