[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Radoslav Husar <rhusar(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
Correct, this is to be expected in ER6 since the changes are not in ER6 codebase yet (useful information now would be to build ER6 + the patch and run the test).
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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, 8 months
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Jitka Kudrnacova <jkudrnac(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
The issue is still present in ER6.
Link to job (note: this is the first job run today with ER6 where this issue was seen again. If you need to verify if this is present in any other test configuration, please let us know):
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-http...
Link to server logs:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-http...
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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, 8 months
[JBoss JIRA] (ISPN-3066) Unable to add two custom interceptors
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-3066:
---------------------------------
Summary: Unable to add two custom interceptors
Key: ISPN-3066
URL: https://issues.jboss.org/browse/ISPN-3066
Project: Infinispan
Issue Type: Bug
Components: Configuration
Affects Versions: 5.3.0.Alpha1
Reporter: Pedro Ruivo
Assignee: Mircea Markus
Exception thrown while it tries to invoke the start() in the second custom interceptor:
{code}
org.infinispan.CacheException: Unable to invoke method protected void org.infinispan.interceptors.CustomInterceptorTest$SecondCustomInterceptor.start() on object of type FirstCustomInterceptor
{code}
After some digging, I've found that both interceptor share the same MetaData class (note, I've added this print on my local branch only):
{code}
2013-05-01 12:49:37,405 FATAL (testng-CustomInterceptorTest) [org.infinispan.factories.ComponentRegistry] Component: Component{instance=org.infinispan.interceptors.CustomInterceptorTest$FirstCustomInterceptor@4aee260b, name=org.infinispan.interceptors.CustomInterceptorTest$FirstCustomInterceptor}, Metadata: ComponentMetadata{name='org.infinispan.interceptors.base.BaseCustomInterceptor', dependencies=null, injectMetadata=[org.infinispan.factories.components.ComponentMetadata$InjectMetadata@54aa2db, org.infinispan.factories.components.ComponentMetadata$InjectMetadata@6709da93], startMethods=[org.infinispan.factories.components.ComponentMetadata$PrioritizedMethodMetadata@37ed1dbe], stopMethods=[org.infinispan.factories.components.ComponentMetadata$PrioritizedMethodMetadata@303bc1a1], globalScope=false, survivesRestarts=false}
2013-05-01 12:49:37,406 FATAL (testng-CustomInterceptorTest) [org.infinispan.factories.ComponentRegistry] Component: Component{instance=org.infinispan.interceptors.CustomInterceptorTest$SecondCustomInterceptor@5903c29b, name=org.infinispan.interceptors.CustomInterceptorTest$SecondCustomInterceptor}, Metadata: ComponentMetadata{name='org.infinispan.interceptors.base.BaseCustomInterceptor', dependencies=null, injectMetadata=[org.infinispan.factories.components.ComponentMetadata$InjectMetadata@54aa2db, org.infinispan.factories.components.ComponentMetadata$InjectMetadata@6709da93], startMethods=[org.infinispan.factories.components.ComponentMetadata$PrioritizedMethodMetadata@37ed1dbe], stopMethods=[org.infinispan.factories.components.ComponentMetadata$PrioritizedMethodMetadata@303bc1a1], globalScope=false, survivesRestarts=false}
{code}
The test can be found here: https://github.com/pruivo/infinispan/blob/two_custom_interceptors/core/sr...
--
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, 8 months
[JBoss JIRA] (ISPN-694) Create expiration notification for in-memory cache entries
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-694?page=com.atlassian.jira.plugin.s... ]
Galder Zamarreño updated ISPN-694:
----------------------------------
Summary: Create expiration notification for in-memory cache entries (was: Create Expiration Notification)
> Create expiration notification for in-memory cache entries
> ----------------------------------------------------------
>
> Key: ISPN-694
> URL: https://issues.jboss.org/browse/ISPN-694
> Project: Infinispan
> Issue Type: Feature Request
> Components: Eviction
> Environment: any
> Reporter: Edouard Boily
> Assignee: Galder Zamarreño
> Attachments: 01.patch
>
>
> Create a CacheEntryExpired notification and make EvictionManager send this notification when a cache entry is evicted because it is expired.
> Also mage sure the cache entry value is sent over in the event.
> CacheEntryEvicted notification should also send the entry value in the event.
--
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, 8 months
[JBoss JIRA] (ISPN-3064) Extend cache expiration notification to cache stores
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-3064:
--------------------------------------
Summary: Extend cache expiration notification to cache stores
Key: ISPN-3064
URL: https://issues.jboss.org/browse/ISPN-3064
Project: Infinispan
Issue Type: Feature Request
Components: Listeners, Loaders and Stores
Reporter: Galder Zamarreño
Assignee: Mircea Markus
Fix For: 6.0.0.Final
Extend cache entry expiration notifications to situations where CacheStore instances, via purgeExpired(), expire data directly in the cache store. This is an extension of ISPN-694.
--
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, 8 months
[JBoss JIRA] (ISPN-694) Create Expiration Notification
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-694?page=com.atlassian.jira.plugin.s... ]
Galder Zamarreño commented on ISPN-694:
---------------------------------------
>From IRC:
{code}
Apr 29 14:47:51 <pferraro> mmarkus: whoops - I meant, also ISPN-694
Apr 29 14:47:52 <jbossbot> jira [ISPN-694] Create Expiration Notification [Reopened (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/ISPN-694
Apr 29 14:49:04 <pferraro> mmarkus: I'm in the process of redesigning web session clustering for wildfly, and these 2 jiras stand in the way of leveraging infinispan's native expiration and eviction support.
...
Apr 29 18:12:41 <mmarkus1> pferraro: in the scope of ISPN-694, we'd need to make the CacheStore trigger expiration notifications
Apr 29 18:12:42 <jbossbot> jira [ISPN-694] Create Expiration Notification [Reopened (Unresolved) Feature Request, Major, Galder Zamarreño] https://issues.jboss.org/browse/ISPN-694
Apr 29 18:13:25 * manik has quit (Quit: Leaving.)
Apr 29 18:13:39 <mmarkus1> pferraro: are you using a CustomCache store or one that exists in Infinispan?
...
Apr 29 18:27:34 <pferraro> mmarkus1: For my case, if the cache entry was already passivated to a cache store, I only need the expiration notification if a subsequent cache get attempts to load it, but it should have expired.
...
Apr 29 18:28:21 <pferraro> mmarkus1: so - for my case, it is enough that the in-memory entries are promptly expired - stuff in the cache store can receive expiration notifications as they are discovered
Apr 29 18:28:38 <pferraro> mmarkus1: does that make sense?
Apr 29 18:29:55 <pferraro> mmarkus1: So, currently, I'm not using a custom cache store, but rather an existing cache store that emits an expiration notification if it is ever fetched from the store
Apr 29 18:34:28 <mmarkus1> pferraro_afk: yes, thanks!
{code}
So, for Paul's use case, expiration notifications for entries in memory is really what's needed.
Give that as discussed in this JIRA, expiration of entries in cache store would require some careful thought, this part will be deferred until the CacheStore interfaces are redesigned in the next big major API review.
> Create Expiration Notification
> ------------------------------
>
> Key: ISPN-694
> URL: https://issues.jboss.org/browse/ISPN-694
> Project: Infinispan
> Issue Type: Feature Request
> Components: Eviction
> Environment: any
> Reporter: Edouard Boily
> Assignee: Galder Zamarreño
> Attachments: 01.patch
>
>
> Create a CacheEntryExpired notification and make EvictionManager send this notification when a cache entry is evicted because it is expired.
> Also mage sure the cache entry value is sent over in the event.
> CacheEntryEvicted notification should also send the entry value in the event.
--
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, 8 months