[JBoss JIRA] (ISPN-2554) Confusing deprecated config usage at WARN loglevel for eviction wakeUpInterval
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2554?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2554:
-------------------------------------
Assignee: Tristan Tarrant (was: Mircea Markus)
> Confusing deprecated config usage at WARN loglevel for eviction wakeUpInterval
> ------------------------------------------------------------------------------
>
> Key: ISPN-2554
> URL: https://issues.jboss.org/browse/ISPN-2554
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Affects Versions: 5.2.0.Beta4
> Reporter: Thomas Fromm
> Assignee: Tristan Tarrant
> Priority: Minor
>
> This warning appears from time to time at runtime. Its confusing, especially when not using deprecated API. Should be fixed and/or the loglevel should be reduced.
> WARN 27.11.12 14:23:40,842 [RMI TCP Connection(5)-10.66.0.232] Configuration ISPN000153: Ignoring eviction wakeUpInterval configuration since it is deprecated, please configure
> Expiration's wakeUpInterval instead
--
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-2995) AtomicHashMap locking issue [optimistic]
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-2995:
---------------------------------
Summary: AtomicHashMap locking issue [optimistic]
Key: ISPN-2995
URL: https://issues.jboss.org/browse/ISPN-2995
Project: Infinispan
Issue Type: Bug
Components: Fine-grained API
Affects Versions: 5.2.5.Final, 5.3.0.Alpha1
Reporter: Pedro Ruivo
Assignee: Mircea Markus
In OptimisticLockingInterceptor, we are collecting the composite keys from ApplyDeltaCommand is the key belongs to the node:
{code}
case ApplyDeltaCommand.COMMAND_ID:
ApplyDeltaCommand command = (ApplyDeltaCommand) wc;
if (cdl.localNodeIsOwner(command.getKey())) {
Object[] compositeKeys = command.getCompositeKeys();
set.addAll(Arrays.asList(compositeKeys));
}
break;
{code}
However, when we are going to acquire the lock in the node if it is the primary owner:
{code}
protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long lockTimeout, boolean skipLocking) throws InterruptedException {
if (cdl.localNodeIsPrimaryOwner(key)) {
lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking);
} else if (cdl.localNodeIsOwner(key)) {
ctx.getCacheTransaction().addBackupLockForKey(key);
}
}
{code}
The CompositeKey should always acquire the lock.
This is probably a bug. Add an unit test to verify that locking works as expected for AtomicHashMap.
--
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:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
My hunch is that there is still another issue with AtomicMaps and the interaction with the cache store - I'm attempting to reproduce the issue locally.
> 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, 9 months
[JBoss JIRA] (ISPN-2992) Timeout on synchronous XSite backup can hang thread
by Erik Salter (JIRA)
Erik Salter created ISPN-2992:
---------------------------------
Summary: Timeout on synchronous XSite backup can hang thread
Key: ISPN-2992
URL: https://issues.jboss.org/browse/ISPN-2992
Project: Infinispan
Issue Type: Bug
Components: Cross-Site Replication
Affects Versions: 5.2.5.Final
Reporter: Erik Salter
Assignee: Mircea Markus
A thread can hang processing a synchronous XSite response if the decremented timeout value goes negative.
This scenario can occur if backup site A takes a while in returning, exhausting the timeout value. Any subsequent backups can wait on a negative value. If the response never arrives from the JGroups layer, like due to a bridge end restarting, the future will wait forever.
--
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, 9 months