<div dir="ltr">Actually looking into this closer. I have found a way to completely remove the expiration interceptor with minimal drawback. The drawback is that a remove expired command will be generated if a read finds the entry gone is concurrently fired with a write for the same key. But I would say this should happen so infrequently that it probably shouldn't matter.<div><br></div><div>I have put it all on [1] and all the tests seem to pass fine. I want to double check a few things but this should be pretty good.</div><div><br></div><div>[1] <a href="https://github.com/wburns/infinispan/commits/expiration_listener">https://github.com/wburns/infinispan/commits/expiration_listener</a><br><div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 30, 2015 at 5:46 PM Sanne Grinovero <<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wouldn't it be an interesting compromise to make sure we calculate<br>
things like the key's hash only once?<br>
<br>
On 30 November 2015 at 21:54, William Burns <<a href="mailto:mudokonman@gmail.com" target="_blank">mudokonman@gmail.com</a>> wrote:<br>
> I am not sure there is an easy way to consolidate these into a single map,<br>
> since some of these are written to on reads, some on writes and sometimes<br>
> conditionally written to. And then as Dan said they are cleaned up at<br>
> different times possibly.<br>
><br>
> We could do something like states (based on which ones would have written to<br>
> the map), but I think it will get quite complex, especially if we ever add<br>
> more of these map type requirement.<br>
><br>
> On a similar note, I had actually thought of possibly moving the expiration<br>
> check out of the data container and into the entry wrapping interceptor or<br>
> the likes. This would allow for us to remove the expiration map completely<br>
> since we could only raise the extra expiration commands on a read and not<br>
> writes. But this would change the API and I am thinking we can only do this<br>
> for 9.0.<br>
><br>
> On Mon, Nov 30, 2015 at 2:18 PM Dan Berindei <<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a>> wrote:<br>
>><br>
>> The first problem that comes to mind is that context entries are also<br>
>> stored in a map, at least in transactional mode. So access through the<br>
>> context would only be faster in non-tx caches, in tx caches it would<br>
>> not add any benefits.<br>
>><br>
>> I also have some trouble imagining how these temporary entries would<br>
>> be released, since locks, L1 requestors, L1 synchronizers, and write<br>
>> registrations all have their own rules for cleaning up.<br>
>><br>
>> Finally, I'm not sure how much this would help. I actually removed the<br>
>> write registration for everything except RemoveExpiredCommand when<br>
>> testing the HotRod server performance, but I didn't get any<br>
>> significant improvement on my machine. Which was kind of expected,<br>
>> since the benchmark doesn't seem to be CPU-bound, and JFR was showing<br>
>> it with < 1.5% of CPU.<br>
>><br>
>><br>
>> Cheers<br>
>> Dan<br>
>><br>
>><br>
>> On Fri, Nov 27, 2015 at 11:28 AM, Radim Vansa <<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>> wrote:<br>
>> > No thoughts at all? @wburns, could I have your view on this?<br>
>> ><br>
>> > Thanks<br>
>> ><br>
>> > Radim<br>
>> ><br>
>> > On 11/23/2015 04:26 PM, Radim Vansa wrote:<br>
>> >> Hi again,<br>
>> >><br>
>> >> examining some flamegraphs I've found out that recently the<br>
>> >> ExpirationInterceptor has been added, which registers ongoing write in<br>
>> >> a<br>
>> >> hashmap. So at this point we have a map for locks, map for writes used<br>
>> >> for expiration, another two key-addressed maps in L1ManagerImpl and one<br>
>> >> in L1NonTxInterceptor and maybe another maps elsewhere.<br>
>> >><br>
>> >> This makes me think that we could spare map lookups and expensive<br>
>> >> writes<br>
>> >> by providing *single map for temporary per-key data*. A reference to<br>
>> >> the<br>
>> >> entry could be stored in the context to save the lookups. An extreme<br>
>> >> case would be to put this into DataContainer, but I think that this<br>
>> >> would prove too tricky in practice.<br>
>> >><br>
>> >> A downside would be the loss of encapsulation (any component could<br>
>> >> theoretically access e.g. locks), but I don't find that too dramatic.<br>
>> >><br>
>> >> WDYT?<br>
>> >><br>
>> >> Radim<br>
>> >><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Radim Vansa <<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>><br>
>> > JBoss Performance Team<br>
>> ><br>
>> > _______________________________________________<br>
>> > infinispan-dev mailing list<br>
>> > <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div></div></div></div></div>