[JBoss JIRA] (ISPN-2297) Cache restart doesn't work properly
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2297:
----------------------------------
Summary: Cache restart doesn't work properly
Key: ISPN-2297
URL: https://issues.jboss.org/browse/ISPN-2297
Project: Infinispan
Issue Type: Bug
Reporter: Dan Berindei
Assignee: Mircea Markus
Cache restart has at least two issues:
1. If a cache is stopped via {{Cache.stop()}} it will still be returned by {{DefaultCacheManager.getCache()}}. Cache {{start()}} and {{stop()}} are not synchronized in any way, so a {{start()}} call may return before the cache was properly started - just because another thread is in the process of starting it.
2. {{ComponentRegistry}} keeps a few components as fields to speed up access. These components are destroyed on {{stop()}} and re-created on {{start()}}, because they are volatile, but the field references are not updated.
Also, the documentation of {{EmbeddedCacheManager.getCache()}} should say that it will start the cache only if it doesn't exist yet - if the cache is stopped it will return the cache as it was. Alternatively we could change the behaviour of {{getCache()}} to always start the 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, 2 months
[JBoss JIRA] (ISPN-2411) Unmarshalling is not triggered when getting 'old' stored value from RCS (RollUps)
by Tomas Sykora (JIRA)
Tomas Sykora created ISPN-2411:
----------------------------------
Summary: Unmarshalling is not triggered when getting 'old' stored value from RCS (RollUps)
Key: ISPN-2411
URL: https://issues.jboss.org/browse/ISPN-2411
Project: Infinispan
Issue Type: Bug
Environment: Starting Infinispan standalone server instances using Arquillian.
Reporter: Tomas Sykora
Assignee: Mircea Markus
This is connected mainly to RollingUpdates. (See https://community.jboss.org/wiki/RollingUpgradesInInfinispan, part 1, step 3)
Unmarshalling process seems not to be triggered when issuing get on NEW cluster cache to get OLD entry which was stored into OLD cluster cache *before* new cluster starts. (this OLD is configured to be RemoteCacheStore for NEW now)
Remote cache store seems to be configured well. When NEW cache is conf. with eviction, entries are successfully evicted to OLD cache = RCS now. Then they are accessible from NEW cache ok. (Consulting remote cache store = OLD cache) See upper part of trace log fragment [1].
OLD entries which was stored before NEW cluster starts seems NOT to be accessible. See lower part of [1] with asterisk in-line comments.
There arise some questions to answer here:
1) Why there is no unmarshalling process there?
2) Then is case of getting old entry, why is there no question asking: Entry exists in loader?
Note: Cache misses on new as well as old cache increase. It looks like new cache is consulting its cache store for the entry but for the WRONG entry (key which is not unmarshalled correctly).
Feel free to comment, mail me, ping me for any other info which is needed.
[1]: http://pastebin.com/ep0iziyz
--
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, 2 months
[JBoss JIRA] (ISPN-2330) JBossMarshaller uses wrong class resolver after stop/start
by Dennis Reed (JIRA)
Dennis Reed created ISPN-2330:
---------------------------------
Summary: JBossMarshaller uses wrong class resolver after stop/start
Key: ISPN-2330
URL: https://issues.jboss.org/browse/ISPN-2330
Project: Infinispan
Issue Type: Bug
Components: Marshalling
Affects Versions: 5.1.4.FINAL
Reporter: Dennis Reed
Assignee: Galder Zamarreño
org.infinispan.marshall.jboss.JBossMarshaller initializes the classResolver in its inject() method and clears it in its stop() method.
If the cache is stopped and restarted (for example when redeploying a clustered web app in EAP), the wrong class resolver is used.
Either the classResolver should not be removed in stop() (testing with it removed did not show any class leaking issues), or it should be reset in start().
--
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, 2 months
[JBoss JIRA] (ISPN-2398) StaleTransactionCleanupService doesn't unlock keys correctly for optimistic caches
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2398:
-----------------------------------
Summary: StaleTransactionCleanupService doesn't unlock keys correctly for optimistic caches
Key: ISPN-2398
URL: https://issues.jboss.org/browse/ISPN-2398
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.2.0.CR1, 5.2.0.Final
The StaleTransactionCleanupService uses explicit locking in order to unlock the keys for which it is no longer owner as the result of a rebalance.
This works for pessimistic caches but doesn't work for the optimistic ones, as the LockCommand causes an exception when processed by the OptimisticLockingInterceptor
--
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, 2 months
[JBoss JIRA] (ISPN-2389) Replace usage of @deprecated WebSocket code
by Norman Maurer (JIRA)
Norman Maurer created ISPN-2389:
-----------------------------------
Summary: Replace usage of @deprecated WebSocket code
Key: ISPN-2389
URL: https://issues.jboss.org/browse/ISPN-2389
Project: Infinispan
Issue Type: Task
Reporter: Norman Maurer
Assignee: Mircea Markus
Infinispan use the @deprecated WebSocket code of Netty. This will get removed soon as an replacement of this is in the core library thins 3.3.0.Final.
We need to make use of it to make sure Infinispan will not break once upgraded.
--
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, 2 months
[JBoss JIRA] (ISPN-2404) The current cache is not injected into Reducer
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2404:
-----------------------------------
Summary: The current cache is not injected into Reducer
Key: ISPN-2404
URL: https://issues.jboss.org/browse/ISPN-2404
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Reporter: Anna Manukyan
Assignee: Vladimir Blagojevic
The bug relates to ISPN-2181.
The current cache is not injected into Reducer.
The cache is not injected at all when the @Input annotation is used.
The pull request for the reproduction will follow.
--
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, 2 months
[JBoss JIRA] (ISPN-2387) ClusteredGetCommand should not be a VisitableCommand
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-2387:
-----------------------------------
Summary: ClusteredGetCommand should not be a VisitableCommand
Key: ISPN-2387
URL: https://issues.jboss.org/browse/ISPN-2387
Project: Infinispan
Issue Type: Task
Affects Versions: 5.2.0.ALPHA1
Reporter: Adrian Nistor
Assignee: Mircea Markus
Fix For: 5.2.0.CR1
ClusteredGetCommand was made visitable during early phase of NBST implementation and later this was found to be unnecessary and this change should be undone.
--
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, 2 months