Re: [infinispan-dev] Notifications for cache entry expired
by kapil nayar
Hi Manik,
The purpose is the usual that the application would want to take some action
on expiry of the entry. Ofcourse the application can also start a timer in
parallel but those timers may again need to be synced up in case of
distributed apps.
However, your explanation brings out another question - is there an
additional overhead (memory related) using expiry on the cache entries as
compared to keeping an active control over the cache entry creation and
deletion. An application using only cache entries with expiry.
Thanks,
Kapil
>Date: Fri, 18 Jun 2010 22:44:59 +0100
>From: Manik Surtani <manik(a)jboss.org>
>Subject: Re: [infinispan-dev] Notifications for cache entry expired
>To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
>Message-ID: <3EAE786D-FB0E-4217-AE4F-7D270B3A955F(a)jboss.org>
>Content-Type: text/plain; charset=us-ascii
>It is possible, yes, but it will never be very accurate since entries are
only tested for whether they are expired in one of several ways:
>1. A user thread asks for the entry and it has expired. It will then be
removed.
>2. The entry is passivated/overflowed to disk and it has expired. It will
again be removed.
>3. An eviction maintenance thread kicks in and detects that it has
expired. It will again be removed.
>So even if a notification is generated, it will not be generated at the
time the entry expired, but rather at the time Infinispan realises the entry
has expired (which may be later).
>Also, what is the purpose of this? It does add quite a bit of overhead.
>Cheers
>Manik
>On 18 Jun 2010, at 18:07, kapil nayar wrote:
> Hi,
>
> I don't see the notification for cache entry expired.
>
> Is it on the roadmap / possible to support?
>
> Thanks,
> Kapil Nayar
>
> ______________________________
_________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>--
>Manik Surtani
>manik(a)jboss.org <manik(a)jboss.org>
>Lead, Infinispan
>Lead, JBoss Cache
>http://www.infinispan.org <http://www.infinispan.org/>
>http://www.jbosscache.org <http://www.jbosscache.org/>
13 years, 11 months
2 questions , may be have one bug
by FangYuan
Hi guys:
I met two problem . Could someone help me?
The first problme is NullPointerException when using replaceAsync
function . The stacks like :
java.lang.NullPointerException
at
org.infinispan.util.concurrent.locks.containers.AbstractStripedLockContainer.hash(AbstractStripedLockContainer.java:65)
at
org.infinispan.util.concurrent.locks.containers.AbstractStripedLockContainer.hashToIndex(AbstractStripedLockContainer.java:54)
at
org.infinispan.util.concurrent.locks.containers.OwnableReentrantStripedLockContainer.getLock(OwnableReentrantStripedLockContainer.java:62)
at
org.infinispan.util.concurrent.locks.containers.OwnableReentrantStripedLockContainer.ownsLock(OwnableReentrantStripedLockContainer.java:66)
at
org.infinispan.util.concurrent.locks.LockManagerImpl.ownsLock(LockManagerImpl.java:122)
at
org.infinispan.util.concurrent.locks.DeadlockDetectingLockManager.localVsLocalDld(DeadlockDetectingLockManager.java:94)
at
org.infinispan.util.concurrent.locks.DeadlockDetectingLockManager.lockAndRecord(DeadlockDetectingLockManager.java:78)
at
org.infinispan.container.EntryFactoryImpl.acquireLock(EntryFactoryImpl.java:205)
at
org.infinispan.container.EntryFactoryImpl.wrapEntryForWriting(EntryFactoryImpl.java:148)
at
org.infinispan.container.EntryFactoryImpl.wrapEntryForWriting(EntryFactoryImpl.java:106)
at
org.infinispan.interceptors.LockingInterceptor.visitLockControlCommand(LockingInterceptor.java:146)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at
org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at
org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at
org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.ImplicitEagerLockingInterceptor.lockEagerly(ImplicitEagerLockingInterceptor.java:96)
at
org.infinispan.interceptors.ImplicitEagerLockingInterceptor.visitReplaceCommand(ImplicitEagerLockingInterceptor.java:61)
at
org.infinispan.commands.write.ReplaceCommand.acceptVisitor(ReplaceCommand.java:58)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:183)
at
org.infinispan.interceptors.TxInterceptor.visitReplaceCommand(TxInterceptor.java:142)
at
org.infinispan.commands.write.ReplaceCommand.acceptVisitor(ReplaceCommand.java:58)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:48)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:34)
at
org.infinispan.commands.AbstractVisitor.visitReplaceCommand(AbstractVisitor.java:65)
at
org.infinispan.commands.write.ReplaceCommand.acceptVisitor(ReplaceCommand.java:58)
at
org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:269)
at
org.infinispan.CacheDelegate.replaceAsync(CacheDelegate.java:590)
at
org.infinispan.CacheDelegate.replaceAsync(CacheDelegate.java:579)
I have checked the source code of infinispan . The reason is the key
value is null, when using null to get hash value jvm will throw a
nullpointerexcetpoin. But I have check the input value from our log and
infinispan's log (trace level). It seems this case will only happened in
multi-thread environment. I think the problem is in lockAndRecord
function of DeadlockDetectingLockManager class.
lockOwnerTx.getLockIntention is null.
I don't know the reason why intention is null and how to fix this
problem . My temp solution is adding a judgement that when only
intention is not null localVsLocalDld function will be called . Is that
ok?
The second problem is replaceAsync function will create a new entry when
cache is in eager locking mode. I think replaceAsync should not have two
different behaviors in different mode . And also I think the eager
locking is only used for get global lock when infinispan run in cluster
mode . I don't know why replaceAsync function related to it . Also I
have check the code .
if (cacheEntry != null) {
if (trace) log.trace("Retrieved from container.");
// exists in cache! Just acquire lock if needed, and wrap.
// do we need a lock?
boolean needToCopy = alreadyLocked || lockAcquired ||
ctx.hasFlag(Flag.SKIP_LOCKING); // even if we do not acquire a lock, if
skip-locking is enabled we should copy
mvccEntry = createWrappedEntry(key, cacheEntry.getValue(),
false, false, cacheEntry.getLifespan());
ctx.putLookedUpEntry(key, mvccEntry);
if (needToCopy) mvccEntry.copyForUpdate(container,
writeSkewCheck);
} else if (createIfAbsent) {
// this is the *only* point where new entries can be
created!!
if (trace) log.trace("Creating new entry.");
// now to lock and create the entry. Lock first to prevent
concurrent creation!
notifier.notifyCacheEntryCreated(key, true, ctx);
mvccEntry = createWrappedEntry(key, null, true, false, -1);
mvccEntry.setCreated(true);
ctx.putLookedUpEntry(key, mvccEntry);
mvccEntry.copyForUpdate(container, writeSkewCheck);
notifier.notifyCacheEntryCreated(key, false, ctx);
} else {
releaseLock(key);
}
Thanks .
The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
13 years, 11 months
Infinispan 5.0 planning meeting @ JBossWorld
by Manik Surtani
So since a number of core Infinispan devs and contributors are at
JBoss World this week we have decided to have an Infinispan 5.0
planning meeting here.
It's going to be at 4:00pm at Campground 1, on Thursday. So if you are
around, and are interested in helping shape what happens in 5.0,
please do join us.
For those not at the event, we will continue the discussion on this
mail list so you won't be (entirely) left out!
Hope to see you there.
- Manik
13 years, 12 months
A missing dependency in cachestore-cloud?
by "이희승 (Trustin Lee)"
Hi folks,
I tried to build the cachestore-cloud module but ended up with a missing
dependency. Do I need to update my ~/.m2/settings.xml? Here's the output:
[INFO] Failed to resolve artifact.
Missing:
----------
1) com.jamesmurty.utils:java-xmlbuilder:jar:0.3
...
Path to dependency:
1) org.infinispan:infinispan-cachestore-cloud:jar:4.1.0-SNAPSHOT
2) org.jclouds:jclouds-aws:jar:1.0-beta-6
3) com.jamesmurty.utils:java-xmlbuilder:jar:0.3
----------
1 required artifact is missing.
for artifact:
org.infinispan:infinispan-cachestore-cloud:jar:4.1.0-SNAPSHOT
Cheers,
Trustin
--
what we call human nature in actuality is human habit
http://gleamynode.net/
14 years
Re: [infinispan-dev] Key locking order in LockingInterceptor
by galder＠jboss.org
Which threads are involved here in the potential deadlock you're talking about?
I'm not sure we could enforce comparable keys since they're outside of the scope of what we can control and keys might not be comparable at all.
Using Comparable though in a test, you might be able to figure out whether the issue is caused by ordering. I.e. you could have two keys which order is swapped at runtime. However, even without using Comparable, it should be relatively easy to spot an issue with locking ordering in the logs (assuming thread info is in logs) cos LockManagerImpl.lockAndRecord logs attempts to locks and whether these were successful.
----- "Vladimir Blagojevic" <vblagoje(a)redhat.com> wrote:
> Hi,
>
> I am trying to figure out why SingleJoinTask sometimes fails due to
> TimeoutException. I noticed that invalidate command sends out bunch of
> keys to be invalidated across cluster and in turn LockingInterceptor
> tries to lock these keys one by one. In few other methods
> LockingInterceptor also tries to lock a list of keys sequentially.
> Without knowing the full details of locking mechanism this practice
> seems to be dangerously susceptible to deadlocks. Shouldn't we require
> all keys to be Comparable so that we can order keys prior to any
> locking attempts in LockingInterceptor.
>
> Maybe I am not understand all the details; I would like to be proven
> that I am completely off :)
>
> Regards,
> Vladimir
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
14 years
Compilation errors in cachestore-remote due to incorrect directory structure
by "이희승 (Trustin Lee)"
Hi folks,
The test classes in cachestore-remote are stored in the wrong directory:
src/test/java/org.infinispan.loaders.remote
where it should be in:
src/test/java/org/infinispan/loaders/remote
What's funny is what Eclipse says about this problem:
The declared package "org.infinispan.loaders.remote" does not match the
expected package "org.infinispan.loaders.remote"
Hence, it took be quite a while to figure out why. :)
Cheers,
Trustin
--
what we call human nature in actuality is human habit
http://gleamynode.net/
14 years
RejectedExecutionException
by Sanne Grinovero
Hello,
I've noticed the forum post about the RejectedExecutionException
experienced under load [1]. In Hibernate Search we had a similar issue
where the producers where quicker than the consumption of tasks; while
I agree about defining a larger queue it's still possible to
experience the error.
What we did there is to customize the ThreadPool factory to have the
caller block waiting for space in the queue when it's full [2].
This seems to me a sane approach, not sure why there's no such policy
by default in j.u.concurrent. am I missing something obvious? or
should we use the same strategy in Infinispan?
Of course you might still want to recommend a larger queue, but at
least it behaves safely in the remaining extreme cases.
See the BlockPolicy in link [2], it was not hard to implement even
while j.u.c doesn't ship such a policy.
[1] - http://community.jboss.org/thread/152661
[2] - http://anonsvn.jboss.org/repos/hibernate/search/trunk/hibernate-search/sr...
Regards,
Sanne
14 years
Key locking order in LockingInterceptor
by Vladimir Blagojevic
Hi,
I am trying to figure out why SingleJoinTask sometimes fails due to TimeoutException. I noticed that invalidate command sends out bunch of keys to be invalidated across cluster and in turn LockingInterceptor tries to lock these keys one by one. In few other methods LockingInterceptor also tries to lock a list of keys sequentially. Without knowing the full details of locking mechanism this practice seems to be dangerously susceptible to deadlocks. Shouldn't we require all keys to be Comparable so that we can order keys prior to any locking attempts in LockingInterceptor.
Maybe I am not understand all the details; I would like to be proven that I am completely off :)
Regards,
Vladimir
14 years
