April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4268) If user sets a cache store using JON console, the cache store does not start without restarting a server instance

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4268?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-4268. --------------------------------- Resolution: Duplicate Issue > If user sets a cache store using JON console, the cache store does not start without restarting a server instance > ------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-4268 > URL: https://issues.jboss.org/browse/ISPN-4268 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Reporter: Suzumura Keishi > Assignee: Tristan Tarrant > Labels: 621 > > If user sets a cache store using JON console, the cache store does not start without restarting a server instance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5147) Creation/configuration of caches should not require a server restart

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5147?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5147: ---------------------------------- Summary: Creation/configuration of caches should not require a server restart (was: Creation/configuration of caches using JON should not require a server restart) > Creation/configuration of caches should not require a server restart > -------------------------------------------------------------------- > > Key: ISPN-5147 > URL: https://issues.jboss.org/browse/ISPN-5147 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > > When creating a cache using the management interface, we want to be able to set all specific configuration and start the cache without requiring a server restart. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5147) Creation/configuration of caches should not require a server restart

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5147?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5147: ---------------------------------- Status: Open (was: New) > Creation/configuration of caches should not require a server restart > -------------------------------------------------------------------- > > Key: ISPN-5147 > URL: https://issues.jboss.org/browse/ISPN-5147 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > > When creating a cache using the management interface, we want to be able to set all specific configuration and start the cache without requiring a server restart. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5366) The method getCacheEntry does not work properly when store as binary is enabled.

by William Burns (JIRA)

William Burns created ISPN-5366: ----------------------------------- Summary: The method getCacheEntry does not work properly when store as binary is enabled. Key: ISPN-5366 URL: https://issues.jboss.org/browse/ISPN-5366 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.1.1.Final Reporter: William Burns The getCacheEntry method doesn't unmarshall values properly. Instead it will return a CacheEntry where the value is a MarshalledValue. We need to unwrap the entry and unmarshall its value before returning. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5147) Creation/configuration of caches using JON should not require a server restart

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5147?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-5147: ------------------------------------- Assignee: Tristan Tarrant (was: William Burns) > Creation/configuration of caches using JON should not require a server restart > ------------------------------------------------------------------------------ > > Key: ISPN-5147 > URL: https://issues.jboss.org/browse/ISPN-5147 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > > When creating a cache using the management interface, we want to be able to set all specific configuration and start the cache without requiring a server restart. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4268) If user sets a cache store using JON console, the cache store does not start without restarting a server instance

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4268?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4268: ------------------------------------- Assignee: Tristan Tarrant > If user sets a cache store using JON console, the cache store does not start without restarting a server instance > ------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-4268 > URL: https://issues.jboss.org/browse/ISPN-4268 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Reporter: Suzumura Keishi > Assignee: Tristan Tarrant > Labels: 621 > > If user sets a cache store using JON console, the cache store does not start without restarting a server instance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5365) JmxManagementIT.testCacheStatisticsAttributes always fails

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5365: ---------------------------------- Summary: JmxManagementIT.testCacheStatisticsAttributes always fails Key: ISPN-5365 URL: https://issues.jboss.org/browse/ISPN-5365 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 7.2.0.Beta2 Reporter: Dan Berindei Assignee: Vladimir Blagojevic Priority: Blocker Fix For: 7.2.0.CR1 Looks like the {{ElapsedTime}} attribute got renamed to {{TimeSinceStart}}, and {{JmxManagementIT}} still uses the old name: {noformat} javax.management.AttributeNotFoundException: Unknown attribute 'ElapsedTime'. Known attributes names are: [numberOfEntries, averageReadTime, hitRatio, timeSinceReset, averageRemoveTime, misses, evictions, readWriteRatio, statisticsEnabled, hits, timeSinceStart, removeMisses, removeHits, stores, averageWriteTime] at org.infinispan.jmx.ResourceDMBean.getAttribute(ResourceDMBean.java:181) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.getAttribute(PluggableMBeanServerImpl.java:1377) at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:384) at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetAttributeHandler.handle(ServerProxy.java:691) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:415) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) {noformat} I think maybe we should keep the old attribute name as well, for backwards compatibility. I'm thinking RHQ might use it... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5365) JmxManagementIT.testCacheStatisticsAttributes always fails

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5365?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5365: ------------------------------- Status: Open (was: New) > JmxManagementIT.testCacheStatisticsAttributes always fails > ----------------------------------------------------------- > > Key: ISPN-5365 > URL: https://issues.jboss.org/browse/ISPN-5365 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 7.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.2.0.CR1 > > > Looks like the {{ElapsedTime}} attribute got renamed to {{TimeSinceStart}}, and {{JmxManagementIT}} still uses the old name: > {noformat} > javax.management.AttributeNotFoundException: Unknown attribute 'ElapsedTime'. Known attributes names are: [numberOfEntries, averageReadTime, hitRatio, timeSinceReset, averageRemoveTime, misses, evictions, readWriteRatio, statisticsEnabled, hits, timeSinceStart, removeMisses, removeHits, stores, averageWriteTime] > at org.infinispan.jmx.ResourceDMBean.getAttribute(ResourceDMBean.java:181) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.getAttribute(PluggableMBeanServerImpl.java:1377) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:384) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetAttributeHandler.handle(ServerProxy.java:691) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:415) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > I think maybe we should keep the old attribute name as well, for backwards compatibility. I'm thinking RHQ might use it... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4795) Warning message about forcing to return previous does not apply to Get operations

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4795?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4795: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1210335|https://bugzilla.redhat.com/show_bug.cgi?id=1210335] from POST to MODIFIED > Warning message about forcing to return previous does not apply to Get operations > --------------------------------------------------------------------------------- > > Key: ISPN-4795 > URL: https://issues.jboss.org/browse/ISPN-4795 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.Final > > > {code} > 'ISPN006010: Operation 'GetRequest' forced to return previous value should be used on transactional caches' in the log > {code} > That message should not appear. GetRequest does not force returning previous. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5356) Transactional, optimistic-locked caches do not honour Flag.FAIL_SILENTLY

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5356?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5356: ----------------------------------- Fix Version/s: 7.2.0.Final > Transactional, optimistic-locked caches do not honour Flag.FAIL_SILENTLY > ------------------------------------------------------------------------ > > Key: ISPN-5356 > URL: https://issues.jboss.org/browse/ISPN-5356 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Environment: Infinispan 6.0.2 > Hibernate ORM 4.3.6 > Apache Tomcat 8 > JDK 1.8.0_25 > Reporter: Mitchell Archibald > Assignee: Galder Zamarreño > Fix For: 7.2.0.Final > > > There is a related issue in the Hibernate JIRA, which can be found at: > https://hibernate.atlassian.net/browse/HHH-7898 > However, I believe this to be an Infinispan issue, as per my analysis below. > The following Exception is thrown when two threads are simultaneously committing a JTA transaction in which an entry has been written to Hibernate's "replicated-query" cache using the same key. > {code} > 10:55:02.238 ERROR saction.TransactionCoordinator - ISPN000255: Error while processing prepare > org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [0 milliseconds] on key [sql: select ...; parameters: ...; named parameters: {...}; transformer: org.hibernate.transform.CacheableResultTransformer@110f2] for requestor [GlobalTransaction:<null>:197882:local]! Lock held by [null] > at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198) > at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171) > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:169) > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:98) > at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.lockAndRecord(OptimisticLockingInterceptor.java:211) > at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitSingleKeyCommand(OptimisticLockingInterceptor.java:206) > at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:199) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70) > at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.acquireLocksVisitingCommands(OptimisticLockingInterceptor.java:270) > at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:75) > at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) > at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) > at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) > at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) > 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.visitPrepareCommand(AbstractVisitor.java:96) > at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) > 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.visitPrepareCommand(AbstractVisitor.java:96) > at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:119) > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:101) > at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:44) > at com.metiom.core.transaction.TransactionImpl.lambda$commit$0(TransactionImpl.java:115) > at com.metiom.core.transaction.TransactionImpl$$Lambda$2/330107372.accept(Unknown Source) > at com.metiom.core.transaction.TransactionImpl.forEachSynchronisation(TransactionImpl.java:264) > at com.metiom.core.transaction.TransactionImpl.commit(TransactionImpl.java:114) > at com.metiom.core.transaction.TransactionManagerImpl.commit(TransactionManagerImpl.java:142) > at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1021) > at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:757) > at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:726) > at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:497) > at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:277) > at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > ... > {code} > The configuration for Hibernate's "replicated-query" cache is as follows (from Hibernate's infinispan-configs.xml) > {code} >  > <namedCache name="replicated-entity"> > <clustering mode="replication"> > <stateTransfer fetchInMemoryState="false" timeout="20000"/> > <sync replTimeout="20000"/> > </clustering> > <locking isolationLevel="READ_COMMITTED" concurrencyLevel="1000" > lockAcquisitionTimeout="15000" useLockStriping="false"/> >  > <eviction maxEntries="10000" strategy="LRU"/> > <expiration maxIdle="100000" wakeUpInterval="5000"/> > <lazyDeserialization enabled="true"/> > <transaction transactionMode="TRANSACTIONAL" autoCommit="false" > lockingMode="OPTIMISTIC"/> > </namedCache> > {code} > Additionally, the cache is configured programmatically with: > * {{Flag.ZERO_LOCK_ACQUISITION_TIMEOUT}}; and > * {{Flag.FAIL_SILENTLY}} > The situation is that two threads are concurrently attempting to lock the same key on commit. > * During a JTA transaction, a Hibernate query is executed, and Hibernate places a result in the query cache. > * On commit, the {{SynchronizationAdaptor}} creates a {{PrepareCommand}}, which contains one or more "modifications", one of which is a {{PutKeyValueCommand}}. The {{SynchronizationAdapter}} invokes the {{PrepareCommand}}. > * When visited, the {{OptimisticLockingInterceptor}} loops through the modifications held by the {{PrepareCommand}} and visits each one. > * When the {{PutKeyValueCommand}} is visited, {{LockManagerImpl}} discovers that the key is locked, and throws {{TimeoutException}}. > * The Exception is caught by {{InvocationContextInterceptor}}, and attempts to find out whether the command it was invoking is affected by {{Flag.FAIL_SILENTLY}}. {{PrepareCommand}} does not implement {{FlagAffectedCommand}}, so this test fails and the Exception is propagated. > It is important to note here that the {{PutKeyValueCommand}} _does_ implement {{FlagAffectedCommand}}, and _does_ have the {{Flag.FAIL_SILENTLY}} flag set. So the problem seems to be that {{OptimisticLockingInterceptor}} is unaware that the modifications to the {{PrepareCommand}} could throw Exceptions which can be suppressed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2015