From bban at redhat.com  Mon Feb  2 02:30:07 2015
From: bban at redhat.com (Bela Ban)
Date: Mon, 02 Feb 2015 08:30:07 +0100
Subject: [infinispan-dev] Student / Contributor projects
In-Reply-To: <1238144212.2567122.1422507303008.JavaMail.zimbra@redhat.com>
References: <54C8AE32.90200@redhat.com>
	<1238144212.2567122.1422507303008.JavaMail.zimbra@redhat.com>
Message-ID: <54CF277F.4000907@redhat.com>

+1000. This would be very useful, not just for support, but also for 
developers, to see if the data flows they see are the ones the expect

On 29/01/15 05:55, Tomas Sykora wrote:
> Hello :)
> As one of those who successfully used Infinispan related topic for diploma thesis I am a big fan of this initiative.
>
> Radim had an idea about capturing, visualizing and storing a history of inter-node communication. I personally feel that Infinispan Management Console could be possibly the right "platform" where to gather, store and visualize such a kind of information. This can also be used for demonstrative purposes (but not only!).
>
> Maybe we would need "a hook" from JGroups (other components?) to gather needed data more easily. Radim's intention was mainly driven by the idea of having ability to see inter-node communication clearly in order to be able to find corrupted message/data flow and spot complicated bugs while one does not need to grep through gigabytes of text-logs.
>
> I can definitely do a research about what is possible, what would be needed and provide more information or even define the topic of diploma thesis itself in the future. Then I can try to ask students at faculty if anyone would be interested.
>
> Thanks!
> Tomas
>
> ----- Original Message -----
>> From: "Tristan Tarrant" <ttarrant at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Sent: Wednesday, January 28, 2015 10:38:58 AM
>> Subject: [infinispan-dev] Student / Contributor projects
>>
>> Hi all,
>>
>> I was told that our student/contributor project page is awfully
>> out-of-date, so we're in need of a big refresh. We should also move that
>> page to the website.
>> Here are some ideas I have collected:
>>
>> - ISPN-5185 Add topology headers to the RESTful server
>> - ISPN-5186 intelligent (L2/L3) Java REST client
>> - ISPN-5187 Node.js HotRod client (either pure-Javascript or based on
>> the C++ client)
>> - ISPN-5188 Support for JSON as indexable/queryable objects using the
>> ProtoBuf schema definitions (this could be extended to XML too)
>> - ISPN-5189 Allow setting a "computing" function (using JDK 8's lambdas)
>> on a cache so that entries can be computed on-demand when they are
>> missing/expired
>>
>> More ideas please
>>
>> Tristan
>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

From ttarrant at redhat.com  Mon Feb  2 04:37:08 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 02 Feb 2015 10:37:08 +0100
Subject: [infinispan-dev] Embedded Tutorial
Message-ID: <54CF4544.5040807@redhat.com>

Well, I have finally finished the Embedded Tutorial complete with code 
and website.

The code is available at

https://github.com/infinispan/infinispan-embedded-tutorial

I have updated the PR at

https://github.com/infinispan/infinispan.github.io/pull/11

and I have staged the site at

http://stg-ispn.rhcloud.com/tutorials/embedded/

until someone else stages something different :)

A few notes:
- I have created two site "partials" and a "template" which can be used 
to add other tutorials
- The tutorial is linked from the "Docs" page
- I have included a script which retags all single commits as steps
- The clustered steps require launching each "node" from a separate 
terminal. I prefer this approach over launching everything "in one step" 
since it allows users to experiment with launching on separate boxes
- I am using highlight.js to provide code prettifying
- I am hiding output by default using a collapsed accordion
- The names of the cities in the tutorial are oh-so-random :)

Tristan

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat


From dan.berindei at gmail.com  Tue Feb  3 06:32:12 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Tue, 3 Feb 2015 13:32:12 +0200
Subject: [infinispan-dev] state transfer timed out, where to configure?
In-Reply-To: <54CA6D02.1030009@nexustelecom.com>
References: <54CA6D02.1030009@nexustelecom.com>
Message-ID: <CA+nfvwS5M1kEQ4+fphYZZfd3-Fpkb0HzHS_=21ozUKFgHXdxkw@mail.gmail.com>

Hi Andreas

Yes, that's the one. 1200s sounds like a huge timeout, though, how big is
your cache?

Cheers
Dan


On Thu, Jan 29, 2015 at 7:25 PM, Andreas Kruthoff <
andreas.kruthoff at nexustelecom.com> wrote:

> Hi dev
>
>
> I'm running into the following exception on the 3rd node out of 2.
> Distributed cluster, file store with a few millions of entries.
>
> The 3rd node times out during startup, I think. "Initial state transfer
> timed out". How can I configure/increase the timeout in my infinispan.xml?
>
> Is it <state-transfer timeout="1200000"/> within <distributed cache/> ?
>
>
> thanks for help
>
> -andreas
>
>
> Exception in thread "main" org.infinispan.commons.CacheException: Unable
> to invoke method public void
>
> org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
> th
> rows java.lang.InterruptedException on object of type
> StateTransferManagerImpl
>          at
>
> org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
>          at
>
> org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
>          at
>
> org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
>          at
>
> org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
>          at
>
> org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
>          at
>
> org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
>          at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:813)
>          at
>
> org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:584)
>          at
>
> org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:539)
>          at
>
> org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:416)
>          at ch.nexustelecom.lbd.engine.ImeiCache.init(ImeiCache.java:49)
>          at
>
> ch.nexustelecom.dexclient.engine.DefaultDexClientEngine.init(DefaultDexClientEngine.java:120)
>          at
> ch.nexustelecom.dexclient.DexClient.initClient(DexClient.java:169)
>          at
>
> ch.nexustelecom.dexclient.tool.DexClientManager.startup(DexClientManager.java:196)
>          at
>
> ch.nexustelecom.dexclient.tool.DexClientManager.main(DexClientManager.java:83)
> Caused by: org.infinispan.commons.CacheException: Initial state transfer
> timed out for cache infinicache-lbd-imei on m4sxhpsrm672-11986
>          at
>
> org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:216)
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>          at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.lang.reflect.Method.invoke(Method.java:606)
>          at
>
> org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
>          ... 14 more
>
> This email and any attachment may contain confidential information which
> is intended for use only by the addressee(s) named above. If you received
> this email by mistake, please notify the sender immediately, and delete the
> email from your system. You are prohibited from copying, disseminating or
> otherwise using the email or any attachment.
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150203/869d8197/attachment.html 

From sanne at infinispan.org  Wed Feb  4 08:20:53 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 4 Feb 2015 13:20:53 +0000
Subject: [infinispan-dev] Student / Contributor projects
In-Reply-To: <54CF277F.4000907@redhat.com>
References: <54C8AE32.90200@redhat.com>
	<1238144212.2567122.1422507303008.JavaMail.zimbra@redhat.com>
	<54CF277F.4000907@redhat.com>
Message-ID: <CAFm4XO1OBAw1CuMcG6wSX_-YH7eRfhMumbOzyb0M80c=ZXjqbw@mail.gmail.com>

On 2 February 2015 at 07:30, Bela Ban <bban at redhat.com> wrote:
> +1000. This would be very useful, not just for support, but also for
> developers, to see if the data flows they see are the ones the expect

Problem: I added that "Visualization and tracing of messages between
nodes" 4 years ago on the wiki.

Rather than adding new ideas we should work on a strategy to get it
done; some volunteer to lead it?

@Tomas : +1 to have a visualizer on the Infinispan Management Console,
but I'd also want to be able to enable a creation of such a trace
without needing to run a console.

For example it would be useful to have a utility method to use in our
unit tests, which is able to assert how many network round trips are
expected to be triggered by running the test. I think this would be
quite straight forward by injecting a custom JGroups protocol.

Sanne


>
> On 29/01/15 05:55, Tomas Sykora wrote:
>> Hello :)
>> As one of those who successfully used Infinispan related topic for diploma thesis I am a big fan of this initiative.
>>
>> Radim had an idea about capturing, visualizing and storing a history of inter-node communication. I personally feel that Infinispan Management Console could be possibly the right "platform" where to gather, store and visualize such a kind of information. This can also be used for demonstrative purposes (but not only!).
>>
>> Maybe we would need "a hook" from JGroups (other components?) to gather needed data more easily. Radim's intention was mainly driven by the idea of having ability to see inter-node communication clearly in order to be able to find corrupted message/data flow and spot complicated bugs while one does not need to grep through gigabytes of text-logs.
>>
>> I can definitely do a research about what is possible, what would be needed and provide more information or even define the topic of diploma thesis itself in the future. Then I can try to ask students at faculty if anyone would be interested.
>>
>> Thanks!
>> Tomas
>>
>> ----- Original Message -----
>>> From: "Tristan Tarrant" <ttarrant at redhat.com>
>>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>>> Sent: Wednesday, January 28, 2015 10:38:58 AM
>>> Subject: [infinispan-dev] Student / Contributor projects
>>>
>>> Hi all,
>>>
>>> I was told that our student/contributor project page is awfully
>>> out-of-date, so we're in need of a big refresh. We should also move that
>>> page to the website.
>>> Here are some ideas I have collected:
>>>
>>> - ISPN-5185 Add topology headers to the RESTful server
>>> - ISPN-5186 intelligent (L2/L3) Java REST client
>>> - ISPN-5187 Node.js HotRod client (either pure-Javascript or based on
>>> the C++ client)
>>> - ISPN-5188 Support for JSON as indexable/queryable objects using the
>>> ProtoBuf schema definitions (this could be extended to XML too)
>>> - ISPN-5189 Allow setting a "computing" function (using JDK 8's lambdas)
>>> on a cache so that entries can be computed on-demand when they are
>>> missing/expired
>>>
>>> More ideas please
>>>
>>> Tristan
>>>
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From ttarrant at redhat.com  Wed Feb  4 08:29:49 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 04 Feb 2015 14:29:49 +0100
Subject: [infinispan-dev] Student / Contributor projects
In-Reply-To: <CAFm4XO1OBAw1CuMcG6wSX_-YH7eRfhMumbOzyb0M80c=ZXjqbw@mail.gmail.com>
References: <54C8AE32.90200@redhat.com>	<1238144212.2567122.1422507303008.JavaMail.zimbra@redhat.com>	<54CF277F.4000907@redhat.com>
	<CAFm4XO1OBAw1CuMcG6wSX_-YH7eRfhMumbOzyb0M80c=ZXjqbw@mail.gmail.com>
Message-ID: <54D21ECD.7090000@redhat.com>

I added new ideas, because the ones on that page were outdated, not 
feasible, really hard or not useful to us:

ISPN-57 support GAE: according to the comments, the security policy on 
GAE prevents us from doing most things
ISPN-46[2-6] Handle HTTP & EJB session on other app servers: we know 
through Paul how difficult this is :)

The visualization one would be really nice to have. As for the proof of 
correctness... :)

Tristan


On 04/02/2015 14:20, Sanne Grinovero wrote:
> On 2 February 2015 at 07:30, Bela Ban <bban at redhat.com> wrote:
>> +1000. This would be very useful, not just for support, but also for
>> developers, to see if the data flows they see are the ones the expect
> Problem: I added that "Visualization and tracing of messages between
> nodes" 4 years ago on the wiki.
>
> Rather than adding new ideas we should work on a strategy to get it
> done; some volunteer to lead it?
>
> @Tomas : +1 to have a visualizer on the Infinispan Management Console,
> but I'd also want to be able to enable a creation of such a trace
> without needing to run a console.
>
> For example it would be useful to have a utility method to use in our
> unit tests, which is able to assert how many network round trips are
> expected to be triggered by running the test. I think this would be
> quite straight forward by injecting a custom JGroups protocol.
>
> Sanne
>
>
>> On 29/01/15 05:55, Tomas Sykora wrote:
>>> Hello :)
>>> As one of those who successfully used Infinispan related topic for diploma thesis I am a big fan of this initiative.
>>>
>>> Radim had an idea about capturing, visualizing and storing a history of inter-node communication. I personally feel that Infinispan Management Console could be possibly the right "platform" where to gather, store and visualize such a kind of information. This can also be used for demonstrative purposes (but not only!).
>>>
>>> Maybe we would need "a hook" from JGroups (other components?) to gather needed data more easily. Radim's intention was mainly driven by the idea of having ability to see inter-node communication clearly in order to be able to find corrupted message/data flow and spot complicated bugs while one does not need to grep through gigabytes of text-logs.
>>>
>>> I can definitely do a research about what is possible, what would be needed and provide more information or even define the topic of diploma thesis itself in the future. Then I can try to ask students at faculty if anyone would be interested.
>>>
>>> Thanks!
>>> Tomas
>>>
>>> ----- Original Message -----
>>>> From: "Tristan Tarrant" <ttarrant at redhat.com>
>>>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>>>> Sent: Wednesday, January 28, 2015 10:38:58 AM
>>>> Subject: [infinispan-dev] Student / Contributor projects
>>>>
>>>> Hi all,
>>>>
>>>> I was told that our student/contributor project page is awfully
>>>> out-of-date, so we're in need of a big refresh. We should also move that
>>>> page to the website.
>>>> Here are some ideas I have collected:
>>>>
>>>> - ISPN-5185 Add topology headers to the RESTful server
>>>> - ISPN-5186 intelligent (L2/L3) Java REST client
>>>> - ISPN-5187 Node.js HotRod client (either pure-Javascript or based on
>>>> the C++ client)
>>>> - ISPN-5188 Support for JSON as indexable/queryable objects using the
>>>> ProtoBuf schema definitions (this could be extended to XML too)
>>>> - ISPN-5189 Allow setting a "computing" function (using JDK 8's lambdas)
>>>> on a cache so that entries can be computed on-demand when they are
>>>> missing/expired
>>>>
>>>> More ideas please
>>>>
>>>> Tristan
>>>>
>>>> --
>>>> Tristan Tarrant
>>>> Infinispan Lead
>>>> JBoss, a division of Red Hat
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> --
>> Bela Ban, JGroups lead (http://www.jgroups.org)
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>


-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat


From rory.odonnell at oracle.com  Fri Feb  6 06:28:23 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 06 Feb 2015 11:28:23 +0000
Subject: [infinispan-dev] Early Access builds for JDK 9 b48,
 JDK 8u40 b23 & JDK 7u80 b05 are available on java.net
Message-ID: <54D4A557.4070303@oracle.com>

Hi Galder,

Now that JDK 9 Early Access build images are modular [1], there is a fresh
Early Access build for JDK 9 b48 <https://jdk9.java.net/download/> 
available on java.net.
The summary of  changes are listed here 
<http://www.java.net/download/jdk9/changes/jdk9-b48.html>

In addition, there are new Early Access builds for the ongoing update 
releases.

The Early Access build for JDK 8u40 b23 
<http://jdk8.java.net/download.html> is available on java.net, with the
summary of changes listed here. 
<http://www.java.net/download/jdk8u40/changes/jdk8u40-b23.html>

Finally, the Early Access build for JDK 7u80 b05 
<https://jdk7.java.net/download.html>is available on java.net,
with the summary of changes listed here. 
<http://download.java.net/jdk7u80/changes/jdk7u80-b05.html>

As we enter the later phases of development for JDK 7u80 & JDK 8u40,
please log any show stoppers as soon as possible.

Rgds,Rory

[1] http://mreinhold.org/blog/jigsaw-modular-images

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150206/e93e02ce/attachment.html 

From andreas.kruthoff at nexustelecom.com  Mon Feb  9 05:48:18 2015
From: andreas.kruthoff at nexustelecom.com (Andreas Kruthoff)
Date: Mon, 9 Feb 2015 11:48:18 +0100
Subject: [infinispan-dev] state transfer timed out, where to configure?
In-Reply-To: <CA+nfvwS5M1kEQ4+fphYZZfd3-Fpkb0HzHS_=21ozUKFgHXdxkw@mail.gmail.com>
References: <54CA6D02.1030009@nexustelecom.com>
	<CA+nfvwS5M1kEQ4+fphYZZfd3-Fpkb0HzHS_=21ozUKFgHXdxkw@mail.gmail.com>
Message-ID: <54D89072.3010403@nexustelecom.com>

Thanks. The cache is a distributed cache with 3 nodes and replication
factor 2. It contains ~40 million entries. As soon as a node has loaded
all entries from disk, new entries are added to this node with high
frequency (several thousand/s).

The other nodes might not be up yet. It takes 'forever' to bring them up
then...?

On 02/03/2015 12:32 PM, Dan Berindei wrote:
> Hi Andreas
>
> Yes, that's the one. 1200s sounds like a huge timeout, though, how big
> is your cache?
>
> Cheers
> Dan
>
>
> On Thu, Jan 29, 2015 at 7:25 PM, Andreas Kruthoff
> <andreas.kruthoff at nexustelecom.com
> <mailto:andreas.kruthoff at nexustelecom.com>> wrote:
>
>     Hi dev
>
>
>     I'm running into the following exception on the 3rd node out of 2.
>     Distributed cluster, file store with a few millions of entries.
>
>     The 3rd node times out during startup, I think. "Initial state transfer
>     timed out". How can I configure/increase the timeout in my
>     infinispan.xml?
>
>     Is it <state-transfer timeout="1200000"/> within <distributed cache/> ?
>
>
>     thanks for help
>
>     -andreas
>
>
>     Exception in thread "main" org.infinispan.commons.CacheException: Unable
>     to invoke method public void
>     org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
>     th
>     rows java.lang.InterruptedException on object of type
>     StateTransferManagerImpl
>               at
>     org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
>               at
>     org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
>               at
>     org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
>               at
>     org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
>               at
>     org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
>               at
>     org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
>               at
>     org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:813)
>               at
>     org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:584)
>               at
>     org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:539)
>               at
>     org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:416)
>               at
>     ch.nexustelecom.lbd.engine.ImeiCache.init(ImeiCache.java:49)
>               at
>     ch.nexustelecom.dexclient.engine.DefaultDexClientEngine.init(DefaultDexClientEngine.java:120)
>               at
>     ch.nexustelecom.dexclient.DexClient.initClient(DexClient.java:169)
>               at
>     ch.nexustelecom.dexclient.tool.DexClientManager.startup(DexClientManager.java:196)
>               at
>     ch.nexustelecom.dexclient.tool.DexClientManager.main(DexClientManager.java:83)
>     Caused by: org.infinispan.commons.CacheException: Initial state transfer
>     timed out for cache infinicache-lbd-imei on m4sxhpsrm672-11986
>               at
>     org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:216)
>               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>               at
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>               at
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>               at java.lang.reflect.Method.invoke(Method.java:606)
>               at
>     org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
>               ... 14 more
>
>     This email and any attachment may contain confidential information
>     which is intended for use only by the addressee(s) named above. If
>     you received this email by mistake, please notify the sender
>     immediately, and delete the email from your system. You are
>     prohibited from copying, disseminating or otherwise using the email
>     or any attachment.
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>

This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are prohibited from copying, disseminating or otherwise using the email or any attachment.


From dan.berindei at gmail.com  Mon Feb  9 08:31:50 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Mon, 9 Feb 2015 14:31:50 +0100
Subject: [infinispan-dev] state transfer timed out, where to configure?
In-Reply-To: <54D89072.3010403@nexustelecom.com>
References: <54CA6D02.1030009@nexustelecom.com>
	<CA+nfvwS5M1kEQ4+fphYZZfd3-Fpkb0HzHS_=21ozUKFgHXdxkw@mail.gmail.com>
	<54D89072.3010403@nexustelecom.com>
Message-ID: <CA+nfvwT1aceM1jti+A0w+jW962=AW0r1rzHOohFJKyXHvaiRfg@mail.gmail.com>

I'm not 100% sure, but this sounds like you're hitting ISPN-5141 [1].
Please add your vote, it might make it into 7.2.0.

Lowering the state transfer chunkSize may also help, especially if your
values are large. The chunkSize is the number of entries in a single chunk,
you should aim at making the average chunk <= 500KB.

Cheers
Dan

[1] https://issues.jboss.org/browse/ISPN-5141


On Mon, Feb 9, 2015 at 11:48 AM, Andreas Kruthoff <
andreas.kruthoff at nexustelecom.com> wrote:

> Thanks. The cache is a distributed cache with 3 nodes and replication
> factor 2. It contains ~40 million entries. As soon as a node has loaded
> all entries from disk, new entries are added to this node with high
> frequency (several thousand/s).
>
> The other nodes might not be up yet. It takes 'forever' to bring them up
> then...?
>
> On 02/03/2015 12:32 PM, Dan Berindei wrote:
> > Hi Andreas
> >
> > Yes, that's the one. 1200s sounds like a huge timeout, though, how big
> > is your cache?
> >
> > Cheers
> > Dan
> >
> >
> > On Thu, Jan 29, 2015 at 7:25 PM, Andreas Kruthoff
> > <andreas.kruthoff at nexustelecom.com
> > <mailto:andreas.kruthoff at nexustelecom.com>> wrote:
> >
> >     Hi dev
> >
> >
> >     I'm running into the following exception on the 3rd node out of 2.
> >     Distributed cluster, file store with a few millions of entries.
> >
> >     The 3rd node times out during startup, I think. "Initial state
> transfer
> >     timed out". How can I configure/increase the timeout in my
> >     infinispan.xml?
> >
> >     Is it <state-transfer timeout="1200000"/> within <distributed
> cache/> ?
> >
> >
> >     thanks for help
> >
> >     -andreas
> >
> >
> >     Exception in thread "main" org.infinispan.commons.CacheException:
> Unable
> >     to invoke method public void
> >
>  org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
> >     th
> >     rows java.lang.InterruptedException on object of type
> >     StateTransferManagerImpl
> >               at
> >
>  org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> >               at
> >
>  org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> >               at
> >
>  org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> >               at
> >
>  org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> >               at
> >
>  org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> >               at
> >
>  org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> >               at
> >     org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:813)
> >               at
> >
>  org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:584)
> >               at
> >
>  org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:539)
> >               at
> >
>  org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:416)
> >               at
> >     ch.nexustelecom.lbd.engine.ImeiCache.init(ImeiCache.java:49)
> >               at
> >
>  ch.nexustelecom.dexclient.engine.DefaultDexClientEngine.init(DefaultDexClientEngine.java:120)
> >               at
> >     ch.nexustelecom.dexclient.DexClient.initClient(DexClient.java:169)
> >               at
> >
>  ch.nexustelecom.dexclient.tool.DexClientManager.startup(DexClientManager.java:196)
> >               at
> >
>  ch.nexustelecom.dexclient.tool.DexClientManager.main(DexClientManager.java:83)
> >     Caused by: org.infinispan.commons.CacheException: Initial state
> transfer
> >     timed out for cache infinicache-lbd-imei on m4sxhpsrm672-11986
> >               at
> >
>  org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:216)
> >               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> >               at
> >
>  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >               at
> >
>  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >               at java.lang.reflect.Method.invoke(Method.java:606)
> >               at
> >
>  org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> >               ... 14 more
> >
> >     This email and any attachment may contain confidential information
> >     which is intended for use only by the addressee(s) named above. If
> >     you received this email by mistake, please notify the sender
> >     immediately, and delete the email from your system. You are
> >     prohibited from copying, disseminating or otherwise using the email
> >     or any attachment.
> >
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
>
> This email and any attachment may contain confidential information which
> is intended for use only by the addressee(s) named above. If you received
> this email by mistake, please notify the sender immediately, and delete the
> email from your system. You are prohibited from copying, disseminating or
> otherwise using the email or any attachment.
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150209/ca834cbb/attachment-0001.html 

From andreas.kruthoff at nexustelecom.com  Mon Feb  9 09:52:21 2015
From: andreas.kruthoff at nexustelecom.com (Andreas Kruthoff)
Date: Mon, 9 Feb 2015 15:52:21 +0100
Subject: [infinispan-dev] state transfer timed out, where to configure?
In-Reply-To: <CA+nfvwT1aceM1jti+A0w+jW962=AW0r1rzHOohFJKyXHvaiRfg@mail.gmail.com>
References: <54CA6D02.1030009@nexustelecom.com>	<CA+nfvwS5M1kEQ4+fphYZZfd3-Fpkb0HzHS_=21ozUKFgHXdxkw@mail.gmail.com>	<54D89072.3010403@nexustelecom.com>
	<CA+nfvwT1aceM1jti+A0w+jW962=AW0r1rzHOohFJKyXHvaiRfg@mail.gmail.com>
Message-ID: <54D8C9A5.4000101@nexustelecom.com>

I've added my vote.

I've increased the chunk size-from 512 entries (default) to 10'000
entries, as from the xsd: "The number of cache entries to batch in each
transfer." I thought that an increased chunk-size helps to populate the
cache faster? Or is it the opposite? One entry is very small, just a
Long for key and value.


On 02/09/2015 02:31 PM, Dan Berindei wrote:
> I'm not 100% sure, but this sounds like you're hitting ISPN-5141 [1].
> Please add your vote, it might make it into 7.2.0.
>
> Lowering the state transfer chunkSize may also help, especially if your
> values are large. The chunkSize is the number of entries in a single
> chunk, you should aim at making the average chunk <= 500KB.
>
> Cheers
> Dan
>
> [1] https://issues.jboss.org/browse/ISPN-5141
>
>
> On Mon, Feb 9, 2015 at 11:48 AM, Andreas Kruthoff
> <andreas.kruthoff at nexustelecom.com
> <mailto:andreas.kruthoff at nexustelecom.com>> wrote:
>
>     Thanks. The cache is a distributed cache with 3 nodes and replication
>     factor 2. It contains ~40 million entries. As soon as a node has loaded
>     all entries from disk, new entries are added to this node with high
>     frequency (several thousand/s).
>
>     The other nodes might not be up yet. It takes 'forever' to bring them up
>     then...?
>
>     On 02/03/2015 12:32 PM, Dan Berindei wrote:
>     > Hi Andreas
>     >
>     > Yes, that's the one. 1200s sounds like a huge timeout, though, how big
>     > is your cache?
>     >
>     > Cheers
>     > Dan
>     >
>     >
>     > On Thu, Jan 29, 2015 at 7:25 PM, Andreas Kruthoff
>     > <andreas.kruthoff at nexustelecom.com
>     <mailto:andreas.kruthoff at nexustelecom.com>
>      > <mailto:andreas.kruthoff at nexustelecom.com
>     <mailto:andreas.kruthoff at nexustelecom.com>>> wrote:
>      >
>      >     Hi dev
>      >
>      >
>      >     I'm running into the following exception on the 3rd node out
>     of 2.
>      >     Distributed cluster, file store with a few millions of entries.
>      >
>      >     The 3rd node times out during startup, I think. "Initial
>     state transfer
>      >     timed out". How can I configure/increase the timeout in my
>      >     infinispan.xml?
>      >
>      >     Is it <state-transfer timeout="1200000"/> within <distributed
>     cache/> ?
>      >
>      >
>      >     thanks for help
>      >
>      >     -andreas
>      >
>      >
>      >     Exception in thread "main"
>     org.infinispan.commons.CacheException: Unable
>      >     to invoke method public void
>      >
>       org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
>      >     th
>      >     rows java.lang.InterruptedException on object of type
>      >     StateTransferManagerImpl
>      >               at
>      >
>       org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
>      >               at
>      >
>       org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
>      >               at
>      >
>       org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
>      >               at
>      >
>       org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
>      >               at
>      >
>       org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
>      >               at
>      >
>       org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
>      >               at
>      >     org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:813)
>      >               at
>      >
>       org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:584)
>      >               at
>      >
>       org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:539)
>      >               at
>      >
>       org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:416)
>      >               at
>      >     ch.nexustelecom.lbd.engine.ImeiCache.init(ImeiCache.java:49)
>      >               at
>      >
>       ch.nexustelecom.dexclient.engine.DefaultDexClientEngine.init(DefaultDexClientEngine.java:120)
>      >               at
>      >
>       ch.nexustelecom.dexclient.DexClient.initClient(DexClient.java:169)
>      >               at
>      >
>       ch.nexustelecom.dexclient.tool.DexClientManager.startup(DexClientManager.java:196)
>      >               at
>      >
>       ch.nexustelecom.dexclient.tool.DexClientManager.main(DexClientManager.java:83)
>      >     Caused by: org.infinispan.commons.CacheException: Initial
>     state transfer
>      >     timed out for cache infinicache-lbd-imei on m4sxhpsrm672-11986
>      >               at
>      >
>       org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:216)
>      >               at
>     sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      >               at
>      >
>       sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>      >               at
>      >
>       sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>      >               at java.lang.reflect.Method.invoke(Method.java:606)
>      >               at
>      >
>       org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
>      >               ... 14 more
>      >
>      >     This email and any attachment may contain confidential
>     information
>      >     which is intended for use only by the addressee(s) named
>     above. If
>      >     you received this email by mistake, please notify the sender
>      >     immediately, and delete the email from your system. You are
>      >     prohibited from copying, disseminating or otherwise using the
>     email
>      >     or any attachment.
>      >
>      >     _______________________________________________
>      >     infinispan-dev mailing list
>      > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     <mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>
>     This email and any attachment may contain confidential information
>     which is intended for use only by the addressee(s) named above. If
>     you received this email by mistake, please notify the sender
>     immediately, and delete the email from your system. You are
>     prohibited from copying, disseminating or otherwise using the email
>     or any attachment.
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>

This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are prohibited from copying, disseminating or otherwise using the email or any attachment.


From tsykora at redhat.com  Tue Feb 10 09:28:11 2015
From: tsykora at redhat.com (Tomas Sykora)
Date: Tue, 10 Feb 2015 09:28:11 -0500 (EST)
Subject: [infinispan-dev] Student / Contributor projects
In-Reply-To: <CAFm4XO1OBAw1CuMcG6wSX_-YH7eRfhMumbOzyb0M80c=ZXjqbw@mail.gmail.com>
References: <54C8AE32.90200@redhat.com>
	<1238144212.2567122.1422507303008.JavaMail.zimbra@redhat.com>
	<54CF277F.4000907@redhat.com>
	<CAFm4XO1OBAw1CuMcG6wSX_-YH7eRfhMumbOzyb0M80c=ZXjqbw@mail.gmail.com>
Message-ID: <1910080455.10325853.1423578491275.JavaMail.zimbra@redhat.com>

I might eventually take over the role of someone called: "Student topics coordinator"?  for Infinispan.

Can we elaborate a little bit what should such a person do? What is your (community) expectation?
I will definitely need to estimate how much time it can consume and how it fits into the stack of other activities that I am planning. 
Thanks!
Tom

----- Original Message -----
> From: "Sanne Grinovero" <sanne at infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Sent: Wednesday, February 4, 2015 2:20:53 PM
> Subject: Re: [infinispan-dev] Student / Contributor projects
> 
> On 2 February 2015 at 07:30, Bela Ban <bban at redhat.com> wrote:
> > +1000. This would be very useful, not just for support, but also for
> > developers, to see if the data flows they see are the ones the expect
> 
> Problem: I added that "Visualization and tracing of messages between
> nodes" 4 years ago on the wiki.
> 
> Rather than adding new ideas we should work on a strategy to get it
> done; some volunteer to lead it?
> 
> @Tomas : +1 to have a visualizer on the Infinispan Management Console,
> but I'd also want to be able to enable a creation of such a trace
> without needing to run a console.
> 
> For example it would be useful to have a utility method to use in our
> unit tests, which is able to assert how many network round trips are
> expected to be triggered by running the test. I think this would be
> quite straight forward by injecting a custom JGroups protocol.
> 
> Sanne
> 
> 
> >
> > On 29/01/15 05:55, Tomas Sykora wrote:
> >> Hello :)
> >> As one of those who successfully used Infinispan related topic for diploma
> >> thesis I am a big fan of this initiative.
> >>
> >> Radim had an idea about capturing, visualizing and storing a history of
> >> inter-node communication. I personally feel that Infinispan Management
> >> Console could be possibly the right "platform" where to gather, store and
> >> visualize such a kind of information. This can also be used for
> >> demonstrative purposes (but not only!).
> >>
> >> Maybe we would need "a hook" from JGroups (other components?) to gather
> >> needed data more easily. Radim's intention was mainly driven by the idea
> >> of having ability to see inter-node communication clearly in order to be
> >> able to find corrupted message/data flow and spot complicated bugs while
> >> one does not need to grep through gigabytes of text-logs.
> >>
> >> I can definitely do a research about what is possible, what would be
> >> needed and provide more information or even define the topic of diploma
> >> thesis itself in the future. Then I can try to ask students at faculty if
> >> anyone would be interested.
> >>
> >> Thanks!
> >> Tomas
> >>
> >> ----- Original Message -----
> >>> From: "Tristan Tarrant" <ttarrant at redhat.com>
> >>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> >>> Sent: Wednesday, January 28, 2015 10:38:58 AM
> >>> Subject: [infinispan-dev] Student / Contributor projects
> >>>
> >>> Hi all,
> >>>
> >>> I was told that our student/contributor project page is awfully
> >>> out-of-date, so we're in need of a big refresh. We should also move that
> >>> page to the website.
> >>> Here are some ideas I have collected:
> >>>
> >>> - ISPN-5185 Add topology headers to the RESTful server
> >>> - ISPN-5186 intelligent (L2/L3) Java REST client
> >>> - ISPN-5187 Node.js HotRod client (either pure-Javascript or based on
> >>> the C++ client)
> >>> - ISPN-5188 Support for JSON as indexable/queryable objects using the
> >>> ProtoBuf schema definitions (this could be extended to XML too)
> >>> - ISPN-5189 Allow setting a "computing" function (using JDK 8's lambdas)
> >>> on a cache so that entries can be computed on-demand when they are
> >>> missing/expired
> >>>
> >>> More ideas please
> >>>
> >>> Tristan
> >>>
> >>> --
> >>> Tristan Tarrant
> >>> Infinispan Lead
> >>> JBoss, a division of Red Hat
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >
> > --
> > Bela Ban, JGroups lead (http://www.jgroups.org)
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

From galder at redhat.com  Wed Feb 11 05:29:20 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Wed, 11 Feb 2015 11:29:20 +0100
Subject: [infinispan-dev] Embedded Tutorial
In-Reply-To: <54CF4544.5040807@redhat.com>
References: <54CF4544.5040807@redhat.com>
Message-ID: <52D57A5B-88F6-4723-AE42-18F46243774A@redhat.com>

Great stuff Tristan!! I've been working on a remote tutorial in the past few weeks, so expect some news in that area soon :)

Cheers,

> On 2 Feb 2015, at 10:37, Tristan Tarrant <ttarrant at redhat.com> wrote:
> 
> Well, I have finally finished the Embedded Tutorial complete with code 
> and website.
> 
> The code is available at
> 
> https://github.com/infinispan/infinispan-embedded-tutorial
> 
> I have updated the PR at
> 
> https://github.com/infinispan/infinispan.github.io/pull/11
> 
> and I have staged the site at
> 
> http://stg-ispn.rhcloud.com/tutorials/embedded/
> 
> until someone else stages something different :)
> 
> A few notes:
> - I have created two site "partials" and a "template" which can be used 
> to add other tutorials
> - The tutorial is linked from the "Docs" page
> - I have included a script which retags all single commits as steps
> - The clustered steps require launching each "node" from a separate 
> terminal. I prefer this approach over launching everything "in one step" 
> since it allows users to experiment with launching on separate boxes
> - I am using highlight.js to provide code prettifying
> - I am hiding output by default using a collapsed accordion
> - The names of the cities in the tutorial are oh-so-random :)
> 
> Tristan
> 
> -- 
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarre?o
galder at redhat.com






From tsykora at redhat.com  Fri Feb 13 00:35:58 2015
From: tsykora at redhat.com (Tomas Sykora)
Date: Fri, 13 Feb 2015 00:35:58 -0500 (EST)
Subject: [infinispan-dev] One quite important security + lifespan SO
 questiong needs our attention
In-Reply-To: <1488226233.12439333.1423805132602.JavaMail.zimbra@redhat.com>
Message-ID: <1915492208.12441036.1423805758488.JavaMail.zimbra@redhat.com>

Hello all, 
please pay a little bit attention to:
http://stackoverflow.com/questions/28437038/browser-access-to-the-infinispan-cache-lifespan-for-security-cache-is-not-expiri

"The behavior I am now getting is frustrating." -- switched the red light on.
Please, can someone look at it?

Btw. (see http://stackoverflow.com/questions/tagged/infinispan?sort=unanswered&pageSize=150) we have 140 unanswered questions with Infinispan tag. Some of them are already answered mostly by Galder though; he is doing so via comments. 

Some of them are in "waiting" state where we requested user to specify his Ispn version and we didn't hear back from them. 
Still, many unanswered. I also fully understand that there are some tricky ones. 

My POV in short: 

1) user validates Infinispan and other key-value / hybrid in-vm stores 
2) has a bit of problems with config 
3) raises SO question 
4) he did not get answer within 2 days
5) deletes and forgets about Infinispan
6) trying _other_ solution (project/product)...

One last note -- actually the thing that there is so many new SO questions is very good. It means we have some users around and this number was rapidly increased after latest release. Don't disappoint them, don't put them down.

Thanks!
Tom

From manik at infinispan.org  Mon Feb 16 06:06:56 2015
From: manik at infinispan.org (Manik Surtani)
Date: Mon, 16 Feb 2015 11:06:56 +0000
Subject: [infinispan-dev] One quite important security + lifespan SO
 questiong needs our attention
In-Reply-To: <CAE9acXE5UJ+Lr8DWaqnaKy10ppuDYmxX9PiH9VaopGG4NLB3ow@mail.gmail.com>
References: <1488226233.12439333.1423805132602.JavaMail.zimbra@redhat.com>
	<1915492208.12441036.1423805758488.JavaMail.zimbra@redhat.com>
	<CAE9acXE5UJ+Lr8DWaqnaKy10ppuDYmxX9PiH9VaopGG4NLB3ow@mail.gmail.com>
Message-ID: <CAE9acXF--FDeqWoodsVtbMzy82HfS4dt1_ZWhE9U-ipOd1Ozeg@mail.gmail.com>

On 13 February 2015 at 05:35, Tomas Sykora <tsykora at redhat.com> wrote:

> One last note -- actually the thing that there is so many new SO questions
> is very good. It means we have some users around and this number was
> rapidly increased after latest release. Don't disappoint them, don't put
> them down.


+1.  Don't ignore these, guys!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150216/6034529d/attachment.html 

From dan.berindei at gmail.com  Mon Feb 16 09:19:30 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Mon, 16 Feb 2015 16:19:30 +0200
Subject: [infinispan-dev] One quite important security + lifespan SO
 questiong needs our attention
In-Reply-To: <CAE9acXF--FDeqWoodsVtbMzy82HfS4dt1_ZWhE9U-ipOd1Ozeg@mail.gmail.com>
References: <1488226233.12439333.1423805132602.JavaMail.zimbra@redhat.com>
	<1915492208.12441036.1423805758488.JavaMail.zimbra@redhat.com>
	<CAE9acXE5UJ+Lr8DWaqnaKy10ppuDYmxX9PiH9VaopGG4NLB3ow@mail.gmail.com>
	<CAE9acXF--FDeqWoodsVtbMzy82HfS4dt1_ZWhE9U-ipOd1Ozeg@mail.gmail.com>
Message-ID: <CA+nfvwR4d62jtHqH4ppixo03WdpVZnM_1-tZNSB-x98GbiFhLg@mail.gmail.com>

Nothing to do here, the user answered the question himself :)

Dan


On Mon, Feb 16, 2015 at 1:06 PM, Manik Surtani <manik at infinispan.org> wrote:

>
> On 13 February 2015 at 05:35, Tomas Sykora <tsykora at redhat.com> wrote:
>
>> One last note -- actually the thing that there is so many new SO
>> questions is very good. It means we have some users around and this number
>> was rapidly increased after latest release. Don't disappoint them, don't
>> put them down.
>
>
> +1.  Don't ignore these, guys!
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150216/25307181/attachment-0001.html 

From sanne at infinispan.org  Tue Feb 17 07:23:31 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 17 Feb 2015 12:23:31 +0000
Subject: [infinispan-dev] Volunteers for Devoxx UK [speakers] ?
Message-ID: <CAFm4XO3kh7T9e+cNt4NObE3SHw1u5LVnDzznOTS+YkijDCEbuQ@mail.gmail.com>

Hi all,
the call for papers for Devoxx UK is closing *today*.

In my initial plans we had this lineup to propose to the organizers:
 - Gustavo on some Infinispan Query related topic
 - myself on Hibernate Search

it turns out the event is very close to Red Hat summit so that's a
conflict for Gustavo - though he's the only one in London from the
Infinispan team.

Someone else interested in flying over here for an awesome event? Or
some experienced user/contributor who lives here maybe wants to step
up?
I'd be glad to join as co-presenter or help anyone to get the details right.

[We don't have influence on the selection committee so this is just
about proposing something: we should try to have someone talking about
Infinispan as it's getting great but isn't very well known]

Sanne

From sanne at infinispan.org  Thu Feb 19 11:46:11 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 19 Feb 2015 16:46:11 +0000
Subject: [infinispan-dev] Is it time to reduce the complexity of the
	CacheManager?
Message-ID: <CAFm4XO3Y75+_+7nxHQvQ-A+550p+LZQmpAZjhwUUVkfr7K_3Kw@mail.gmail.com>

All,
at  the beginning of time, the expectation was that an application
server (aka WildFly) would have a single CacheManager, and different
applications would define their different Cache configuration on this
app-server singleton.

In that primitive world that sounded reasonable, as system
administrators wouldn't want to manage firewalls and port assignments
for a new Transport for each deployed application.

Then the complexities came:
 - deployments are asymmetric compared to the application server
 - each deployment has its own ClassLoader
 - deployments start/stop independently from each other

At that point a considerable investment was made to get lazily
starting Caches, per-Cache sets of Externalizer(s) to isolate
classloaders, ClassLoader-aware Cache decorators, up to the recently
introduced Cache-dependency rules for stopping dependant Caches last.

Not to mention we have now a complex per-Cache View handling, which
results in performance complexities such as ISPN-4842.

There are some more complexities coming:
Hibernate OGM wishes to control the context of deserialization - this
is actually an important optimisation to keep garbage production under
control, but also applications might want to register custom RPC
commands; this has been a long standing problem for Search (among
others).
Infinispan Query does have custom RPC commands, and this just happens
to work because the Infinispan core module has an explicit dependency
to query.. but that's a twisted dependency scheme, as the module would
need to list each possible extension point: it's not something you can
do for all projects using it.

Interestingly enough, there is a very simple solution which wipes out
all of the above complexity, and also resolves some pain points:
today the app server supports the FORK protocol from JGroups, so we
can get rid of the idea of a single CacheManager per appserver, and
create one per classloader and *within* the classloader.

By doing so, we can delete all code about per-Cache classloaders,
remove the CacheView concept, and also allow the deployment (the
application) which is needing caching services to register whatever it
wants.
It could register custom interceptors, commands, externalizers,
CacheStore(s), etc.. without pain.

Finally, we could get rid of the concept that Caches start lazily. I'd
change to a simplified lifecycle which expects the CacheManager to
initialize, then allows Cache configurations to be defined, and then
it all starts atomically.
At that point, you'd not even be responsible anymore for complex
dependency resolutions across caches.

I'd hope this would allow OGM to get the features it needs, and also
significantly simplify the definition of boot process for any user,
not least it should simplify quite some code which is now being
maintained.

A nice follow-up task would be that WildFly would need to be able to
"pick up" some configuration file from the deployment and inject a
matching CacheManager, so this requires a bit of cooperation with the
app server team, and an agreement on a conventional configuration
name.
This should be done by WildFly (and not the app), so that the user
deployment can lookup the CacheManager by JNDI without needing to
understand how to wire things up in the FORK channel.

I also believe this is a winner from usability point of view, as many
of the troubles I see in forums and customers are about "how do I
start this up?". Remember our guides essentially teach you to either
take the AS CacheManager, or to start your own. Neither of those are
the optimal solution, and people get in trouble.

WDYT?

Sanne

From ttarrant at redhat.com  Fri Feb 20 03:50:38 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 20 Feb 2015 09:50:38 +0100
Subject: [infinispan-dev] Branched 7.1.x
Message-ID: <54E6F55E.9090105@redhat.com>

Hi all, I have created the 7.1.x branch from which we will be releasing 
7.1.1.Final today.

Tristan

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat


From ttarrant at redhat.com  Fri Feb 20 05:12:55 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 20 Feb 2015 11:12:55 +0100
Subject: [infinispan-dev] Is it time to reduce the complexity of the
	CacheManager?
In-Reply-To: <CAFm4XO3Y75+_+7nxHQvQ-A+550p+LZQmpAZjhwUUVkfr7K_3Kw@mail.gmail.com>
References: <CAFm4XO3Y75+_+7nxHQvQ-A+550p+LZQmpAZjhwUUVkfr7K_3Kw@mail.gmail.com>
Message-ID: <54E708A7.4040604@redhat.com>

Yes, I agree with the rationale.
We should have some kind of entry point, a hypothetical "ClusterManager" 
which would handle common generic components (transport, thread pools, 
...) and be a factory for other subcomponents (CacheManagers and other 
clustered services). Dropping support for asymmetric clusters would mean 
reduced complexity and memory usage.

This gets a big +1 from me.

Tristan

On 19/02/2015 17:46, Sanne Grinovero wrote:
> All,
> at  the beginning of time, the expectation was that an application
> server (aka WildFly) would have a single CacheManager, and different
> applications would define their different Cache configuration on this
> app-server singleton.
>
> In that primitive world that sounded reasonable, as system
> administrators wouldn't want to manage firewalls and port assignments
> for a new Transport for each deployed application.
>
> Then the complexities came:
>   - deployments are asymmetric compared to the application server
>   - each deployment has its own ClassLoader
>   - deployments start/stop independently from each other
>
> At that point a considerable investment was made to get lazily
> starting Caches, per-Cache sets of Externalizer(s) to isolate
> classloaders, ClassLoader-aware Cache decorators, up to the recently
> introduced Cache-dependency rules for stopping dependant Caches last.
>
> Not to mention we have now a complex per-Cache View handling, which
> results in performance complexities such as ISPN-4842.
>
> There are some more complexities coming:
> Hibernate OGM wishes to control the context of deserialization - this
> is actually an important optimisation to keep garbage production under
> control, but also applications might want to register custom RPC
> commands; this has been a long standing problem for Search (among
> others).
> Infinispan Query does have custom RPC commands, and this just happens
> to work because the Infinispan core module has an explicit dependency
> to query.. but that's a twisted dependency scheme, as the module would
> need to list each possible extension point: it's not something you can
> do for all projects using it.
>
> Interestingly enough, there is a very simple solution which wipes out
> all of the above complexity, and also resolves some pain points:
> today the app server supports the FORK protocol from JGroups, so we
> can get rid of the idea of a single CacheManager per appserver, and
> create one per classloader and *within* the classloader.
>
> By doing so, we can delete all code about per-Cache classloaders,
> remove the CacheView concept, and also allow the deployment (the
> application) which is needing caching services to register whatever it
> wants.
> It could register custom interceptors, commands, externalizers,
> CacheStore(s), etc.. without pain.
>
> Finally, we could get rid of the concept that Caches start lazily. I'd
> change to a simplified lifecycle which expects the CacheManager to
> initialize, then allows Cache configurations to be defined, and then
> it all starts atomically.
> At that point, you'd not even be responsible anymore for complex
> dependency resolutions across caches.
>
> I'd hope this would allow OGM to get the features it needs, and also
> significantly simplify the definition of boot process for any user,
> not least it should simplify quite some code which is now being
> maintained.
>
> A nice follow-up task would be that WildFly would need to be able to
> "pick up" some configuration file from the deployment and inject a
> matching CacheManager, so this requires a bit of cooperation with the
> app server team, and an agreement on a conventional configuration
> name.
> This should be done by WildFly (and not the app), so that the user
> deployment can lookup the CacheManager by JNDI without needing to
> understand how to wire things up in the FORK channel.
>
> I also believe this is a winner from usability point of view, as many
> of the troubles I see in forums and customers are about "how do I
> start this up?". Remember our guides essentially teach you to either
> take the AS CacheManager, or to start your own. Neither of those are
> the optimal solution, and people get in trouble.
>
> WDYT?
>
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>


-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat


From ttarrant at redhat.com  Fri Feb 20 12:12:22 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 20 Feb 2015 18:12:22 +0100
Subject: [infinispan-dev] Infinispan 7.1.1.Final released
Message-ID: <54E76AF6.90809@redhat.com>

Hello everyone,

The final release is now available for 7.1.1, providing some small, but important fixes.

Read the blog post for more details: http://blog.infinispan.org/2015/02/infinispan-711final-released.html

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat


From sebastian.laskawiec at gmail.com  Mon Feb 23 12:23:52 2015
From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=)
Date: Mon, 23 Feb 2015 17:23:52 +0000
Subject: [infinispan-dev] Different configuration with Hibernate
Message-ID: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>

Hey!

I've noticed an interesting question on StackOverflow [1]. Is it possible
to have 2 (or more) caches and associate database tables to specific
caches? I can even imagine this question in broader perspective - is it
possible to decide in the runtime, which cache should be used?

After a short discussion with Sanne we couldn't find any solution. Does
anyone have any idea how to achieve this or maybe we have a "New Feature
Request" candidate?

Thanks
Sebastian

[1]
http://stackoverflow.com/questions/28668971/hibernate-different-caches-for-different-tables
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150223/7811083a/attachment.html 

From dan.berindei at gmail.com  Tue Feb 24 06:48:49 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Tue, 24 Feb 2015 13:48:49 +0200
Subject: [infinispan-dev] Is it time to reduce the complexity of the
	CacheManager?
In-Reply-To: <54E708A7.4040604@redhat.com>
References: <CAFm4XO3Y75+_+7nxHQvQ-A+550p+LZQmpAZjhwUUVkfr7K_3Kw@mail.gmail.com>
	<54E708A7.4040604@redhat.com>
Message-ID: <CA+nfvwTuYsttX7Z0NBozok0DQfYYuzu8HEGC58SLGPQDYdfRnQ@mail.gmail.com>

We have talked about dropping support for asymmetric clusters quite a few
times before. I still think it's worth making it look symmetric in the API,
however I'm starting to doubt it will bring a lot of benefits in
simplifying the implementation.

These are the reasons I think we'll need to keep different cache topologies
(and consistent hashes):
a) Having the same consistent hash (or should I say hashing function)
requires some pretty drastic restrictions: the same nodes, number of
segments, capacity factors, and numOwners. In particular enforcing the same
numOwners for all the caches would not allow a distributed cache and a
replicated cache to be part of the same CacheManager.
b) Even if all caches start state transfer at exactly the same time, not
all caches will finish state transfer at the same time. It makes sense to
clean up the  temporary structures related to state transfer as soon as
possible.

Further comments inline...


On Fri, Feb 20, 2015 at 12:12 PM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> Yes, I agree with the rationale.
> We should have some kind of entry point, a hypothetical "ClusterManager"
> which would handle common generic components (transport, thread pools,
> ...) and be a factory for other subcomponents (CacheManagers and other
> clustered services). Dropping support for asymmetric clusters would mean
> reduced complexity and memory usage.
>
> This gets a big +1 from me.
>
> Tristan
>
> On 19/02/2015 17:46, Sanne Grinovero wrote:
> > All,
> > at  the beginning of time, the expectation was that an application
> > server (aka WildFly) would have a single CacheManager, and different
> > applications would define their different Cache configuration on this
> > app-server singleton.
> >
> > In that primitive world that sounded reasonable, as system
> > administrators wouldn't want to manage firewalls and port assignments
> > for a new Transport for each deployed application.
> >
> > Then the complexities came:
> >   - deployments are asymmetric compared to the application server
> >   - each deployment has its own ClassLoader
> >   - deployments start/stop independently from each other
> >
> > At that point a considerable investment was made to get lazily
> > starting Caches, per-Cache sets of Externalizer(s) to isolate
> > classloaders, ClassLoader-aware Cache decorators, up to the recently
> > introduced Cache-dependency rules for stopping dependant Caches last.
>

I don't think we ever had a per-Cache set of Externalizers, that's what
ISPN-2133 is about...

AFAIK the classloader-aware decorators work only with storeAsBinary
enabled, and they actually enable users to share the same Cache (not
CacheManager) between deployments. I'm not sure how many users need that,
but we need to think hard about dropping support for the decorators (and
the related support for Thread.getContextClassLoader()).


>
> > Not to mention we have now a complex per-Cache View handling, which
> > results in performance complexities such as ISPN-4842.
>

I believe we will still need the per-Cache topologies (i.e. consistent
hashes), possibly with bulk join operations and memoization to help with
performance.

Note that ISPN-4842 talks about evolving from 500 caches to 3000 caches.
Should we require the application to use an extra CacheManager every time
it needs a new Cache?


>
> > There are some more complexities coming:
> > Hibernate OGM wishes to control the context of deserialization - this
> > is actually an important optimisation to keep garbage production under
> > control, but also applications might want to register custom RPC
> > commands; this has been a long standing problem for Search (among
> > others).
> > Infinispan Query does have custom RPC commands, and this just happens
> > to work because the Infinispan core module has an explicit dependency
> > to query.. but that's a twisted dependency scheme, as the module would
> > need to list each possible extension point: it's not something you can
> > do for all projects using it.
>

Indeed, the WildFly module that applications depend on now needs to have
access to query classes, but I think that's just a matter of supplying the
proper ClassLoader to GlobalConfigurationBuilder. Fixing it shouldn't
require core changes.

For OGM, would having the deployment's ClassLoader in the
GlobalConfiguration remove the need of a per-Cache deserialization context?



> >
> > Interestingly enough, there is a very simple solution which wipes out
> > all of the above complexity, and also resolves some pain points:
> > today the app server supports the FORK protocol from JGroups, so we
> > can get rid of the idea of a single CacheManager per appserver, and
> > create one per classloader and *within* the classloader.
>

I guess Paul should chime in here, is it feasible to create the
CacheManager(s) required for a deployment only after the module has been
loaded and a proper classloader has been instantiated?


>
> > By doing so, we can delete all code about per-Cache classloaders,
> > remove the CacheView concept, and also allow the deployment (the
> > application) which is needing caching services to register whatever it
> > wants.
> > It could register custom interceptors, commands, externalizers,
> > CacheStore(s), etc.. without pain.
>

To be clear, we already removed the per-Cache classloaders some time ago.
All we have now is the per-CacheManager classloader, the thread-context
classloader, and the classloader decorator. And I don't feel I know enough
about how the latter two are used now to decide whether to remove them or
not...


> >
> > Finally, we could get rid of the concept that Caches start lazily. I'd
> > change to a simplified lifecycle which expects the CacheManager to
> > initialize, then allows Cache configurations to be defined, and then
> > it all starts atomically.
> > At that point, you'd not even be responsible anymore for complex
> > dependency resolutions across caches.
>

How would that work? I.e. if I define an indexed cache (either in the
configuration or in a module), when would the indexed cache define the
cache it needs to store its index?

+1 to start all the defined caches when the CacheManager starts, but I
would still like to be able to start a temporary cache and then stop it for
Map/Reduce, instead of having to spin up an entire CacheManager.



> >
> > I'd hope this would allow OGM to get the features it needs, and also
> > significantly simplify the definition of boot process for any user,
> > not least it should simplify quite some code which is now being
> > maintained.
> >
> > A nice follow-up task would be that WildFly would need to be able to
> > "pick up" some configuration file from the deployment and inject a
> > matching CacheManager, so this requires a bit of cooperation with the
> > app server team, and an agreement on a conventional configuration
> > name.
> > This should be done by WildFly (and not the app), so that the user
> > deployment can lookup the CacheManager by JNDI without needing to
> > understand how to wire things up in the FORK channel.
> >
> > I also believe this is a winner from usability point of view, as many
> > of the troubles I see in forums and customers are about "how do I
> > start this up?". Remember our guides essentially teach you to either
> > take the AS CacheManager, or to start your own. Neither of those are
> > the optimal solution, and people get in trouble.
>

I think looking up a "forkable channel" in JNDI and calling new
DefaultCacheManager() with that should be easy enough, if it's properly
documented :)

One thing I've seen people ask about many times is sharing a
Cache/CacheManager between deployments. Granted, some of those questions
might have actually needed only a way to share the transport, but others
probably really needed to access the same data. Having a clear way to
instantiate the CacheManager and put it up in JNDI from a common dependency
would definitely be a plus.


Cheers
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150224/1754e25e/attachment-0001.html 

From dan.berindei at gmail.com  Tue Feb 24 07:13:33 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Tue, 24 Feb 2015 14:13:33 +0200
Subject: [infinispan-dev] Different configuration with Hibernate
In-Reply-To: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>
References: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>
Message-ID: <CA+nfvwR7xzXOzMOCQFs8YxkNzfd1cJN4FiRFmahMtMdk_d9m1g@mail.gmail.com>

I believe the user guide has the answer to the original question:

http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_advanced_configuration_2

> On top of that, this finer grained cache definition enables users to define cache settings on a per entity/collection basis. For example:
>
> <!-- If using JPA, add to your persistence.xml -->
> <property name="hibernate.cache.infinispan.com.acme.Person.cfg"
>    value="person-entity"/>
> <property name="hibernate.cache.infinispan.com.acme.Person.addresses.cfg"
>    value="addresses-collection"/>


I don't think the mapping can be changed at runtime, though.


Cheers
Dan


On Mon, Feb 23, 2015 at 7:23 PM, Sebastian ?askawiec
<sebastian.laskawiec at gmail.com> wrote:
> Hey!
>
> I've noticed an interesting question on StackOverflow [1]. Is it possible to
> have 2 (or more) caches and associate database tables to specific caches? I
> can even imagine this question in broader perspective - is it possible to
> decide in the runtime, which cache should be used?
>
> After a short discussion with Sanne we couldn't find any solution. Does
> anyone have any idea how to achieve this or maybe we have a "New Feature
> Request" candidate?
>
> Thanks
> Sebastian
>
> [1]
> http://stackoverflow.com/questions/28668971/hibernate-different-caches-for-different-tables
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From sanne at infinispan.org  Tue Feb 24 07:23:26 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 24 Feb 2015 12:23:26 +0000
Subject: [infinispan-dev] Different configuration with Hibernate
In-Reply-To: <CA+nfvwR7xzXOzMOCQFs8YxkNzfd1cJN4FiRFmahMtMdk_d9m1g@mail.gmail.com>
References: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>
	<CA+nfvwR7xzXOzMOCQFs8YxkNzfd1cJN4FiRFmahMtMdk_d9m1g@mail.gmail.com>
Message-ID: <CAFm4XO10hWvUCuci3yec7=_4vXvNb5ypEVWJ9rwaTVpvLE_14w@mail.gmail.com>

Interesting, so it seems it's possible to configure a specific cache
for a specific entity?

I thought this was a pending limitation of the Infinispan Cache, and
I'm afraid most other users will think it too as none of this is
mentioned in the Hibernate documentation.



On 24 February 2015 at 12:13, Dan Berindei <dan.berindei at gmail.com> wrote:
> I believe the user guide has the answer to the original question:
>
> http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_advanced_configuration_2
>
>> On top of that, this finer grained cache definition enables users to define cache settings on a per entity/collection basis. For example:
>>
>> <!-- If using JPA, add to your persistence.xml -->
>> <property name="hibernate.cache.infinispan.com.acme.Person.cfg"
>>    value="person-entity"/>
>> <property name="hibernate.cache.infinispan.com.acme.Person.addresses.cfg"
>>    value="addresses-collection"/>
>
>
> I don't think the mapping can be changed at runtime, though.
>
>
> Cheers
> Dan
>
>
> On Mon, Feb 23, 2015 at 7:23 PM, Sebastian ?askawiec
> <sebastian.laskawiec at gmail.com> wrote:
>> Hey!
>>
>> I've noticed an interesting question on StackOverflow [1]. Is it possible to
>> have 2 (or more) caches and associate database tables to specific caches? I
>> can even imagine this question in broader perspective - is it possible to
>> decide in the runtime, which cache should be used?
>>
>> After a short discussion with Sanne we couldn't find any solution. Does
>> anyone have any idea how to achieve this or maybe we have a "New Feature
>> Request" candidate?
>>
>> Thanks
>> Sebastian
>>
>> [1]
>> http://stackoverflow.com/questions/28668971/hibernate-different-caches-for-different-tables
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From andreas.kruthoff at nexustelecom.com  Tue Feb 24 09:11:23 2015
From: andreas.kruthoff at nexustelecom.com (Andreas Kruthoff)
Date: Tue, 24 Feb 2015 15:11:23 +0100
Subject: [infinispan-dev] NPE in SingleFileStore during node shutdown
Message-ID: <54EC868B.2010900@nexustelecom.com>

Hi Dev


 From time to time, I'm running into this exception which causes the
node to hang.

Exception in thread "persistence-thread--p5-t1"
org.infinispan.persistence.spi.PersistenceException:
java.lang.NullPointerException
        at
org.infinispan.persistence.file.SingleFileStore$2.run(SingleFileStore.java:672)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
        at
org.infinispan.persistence.file.SingleFileStore.free(SingleFileStore.java:306)
        at
org.infinispan.persistence.file.SingleFileStore.access$1200(SingleFileStore.java:63)
        at
org.infinispan.persistence.file.SingleFileStore$2.run(SingleFileStore.java:670)
        ... 3 more


My scenario:

Start 3 distributed nodes, owners="2", filestore with preload="true"
shared="true" purge="false". About 20 Mio entries in the .dat file.

The state-transfer takes about 5 Minutes, the cluster is ready
afterwards, but still very busy operating on the filestore!

If I stop a node now, the exception happens. If I wait for about 30
Minutes (after the cpu load reduces), and the shutdown of a node works
without problems. It persists its entries.

Shall I create a JIRA or am I missing something?

This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are prohibited from copying, disseminating or otherwise using the email or any attachment.


From emmanuel at hibernate.org  Tue Feb 24 12:47:19 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 24 Feb 2015 18:47:19 +0100
Subject: [infinispan-dev] [Query] Continuous queries 1-1 modify case
Message-ID: <74C6B9E4-5802-4382-821B-50AC9C862865@hibernate.org>

While discussing with Stelios, I realised that it is useful in some circumstances to receive a notification in case of a 1-1 transition.

This diff captures the design improvements
https://github.com/infinispan/infinispan/wiki/Continuous-query-design-and-indexless-queries/_compare/fd92aa7b0f95fc117b5b6ea9a84bb61c16b3be7e...b77fc2907bac26c53d631dbb35a67c9e1d428656 <https://github.com/infinispan/infinispan/wiki/Continuous-query-design-and-indexless-queries/_compare/fd92aa7b0f95fc117b5b6ea9a84bb61c16b3be7e...b77fc2907bac26c53d631dbb35a67c9e1d428656>

Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150224/71bb2750/attachment.html 

From anistor at redhat.com  Wed Feb 25 04:47:07 2015
From: anistor at redhat.com (Adrian Nistor)
Date: Wed, 25 Feb 2015 11:47:07 +0200
Subject: [infinispan-dev] Infinispan 7.2.0.Alpha1 released
Message-ID: <54ED9A1B.4060107@redhat.com>

Dear Infinispan community,

Infinispan 7.2.0.Alpha1 is now available!

Read more at: 
http://blog.infinispan.org/2015/02/infinispan-720alpha1-released.html


From galder at redhat.com  Wed Feb 25 07:51:57 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Wed, 25 Feb 2015 13:51:57 +0100
Subject: [infinispan-dev] Different configuration with Hibernate
In-Reply-To: <CAFm4XO10hWvUCuci3yec7=_4vXvNb5ypEVWJ9rwaTVpvLE_14w@mail.gmail.com>
References: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>
	<CA+nfvwR7xzXOzMOCQFs8YxkNzfd1cJN4FiRFmahMtMdk_d9m1g@mail.gmail.com>
	<CAFm4XO10hWvUCuci3yec7=_4vXvNb5ypEVWJ9rwaTVpvLE_14w@mail.gmail.com>
Message-ID: <E4497414-B16C-450C-B400-67E102B5EE79@redhat.com>


> On 24 Feb 2015, at 13:23, Sanne Grinovero <sanne at infinispan.org> wrote:
> 
> Interesting, so it seems it's possible to configure a specific cache
> for a specific entity?

Yes. It's been possible since the very first Infinispan 2LC implementation. The advanced configuration section in [1] explains how to do so.

[1] http://infinispan.org/docs/7.1.x/user_guide/user_guide.html#_advanced_configuration_2

> I thought this was a pending limitation of the Infinispan Cache, and
> I'm afraid most other users will think it too as none of this is
> mentioned in the Hibernate documentation.
> 
> 
> 
> On 24 February 2015 at 12:13, Dan Berindei <dan.berindei at gmail.com> wrote:
>> I believe the user guide has the answer to the original question:
>> 
>> http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_advanced_configuration_2
>> 
>>> On top of that, this finer grained cache definition enables users to define cache settings on a per entity/collection basis. For example:
>>> 
>>> <!-- If using JPA, add to your persistence.xml -->
>>> <property name="hibernate.cache.infinispan.com.acme.Person.cfg"
>>>   value="person-entity"/>
>>> <property name="hibernate.cache.infinispan.com.acme.Person.addresses.cfg"
>>>   value="addresses-collection"/>
>> 
>> 
>> I don't think the mapping can be changed at runtime, though.
>> 
>> 
>> Cheers
>> Dan
>> 
>> 
>> On Mon, Feb 23, 2015 at 7:23 PM, Sebastian ?askawiec
>> <sebastian.laskawiec at gmail.com> wrote:
>>> Hey!
>>> 
>>> I've noticed an interesting question on StackOverflow [1]. Is it possible to
>>> have 2 (or more) caches and associate database tables to specific caches? I
>>> can even imagine this question in broader perspective - is it possible to
>>> decide in the runtime, which cache should be used?
>>> 
>>> After a short discussion with Sanne we couldn't find any solution. Does
>>> anyone have any idea how to achieve this or maybe we have a "New Feature
>>> Request" candidate?
>>> 
>>> Thanks
>>> Sebastian
>>> 
>>> [1]
>>> http://stackoverflow.com/questions/28668971/hibernate-different-caches-for-different-tables
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarre?o
galder at redhat.com






From galder at redhat.com  Wed Feb 25 07:55:34 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Wed, 25 Feb 2015 13:55:34 +0100
Subject: [infinispan-dev] Different configuration with Hibernate
In-Reply-To: <CAFm4XO10hWvUCuci3yec7=_4vXvNb5ypEVWJ9rwaTVpvLE_14w@mail.gmail.com>
References: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>
	<CA+nfvwR7xzXOzMOCQFs8YxkNzfd1cJN4FiRFmahMtMdk_d9m1g@mail.gmail.com>
	<CAFm4XO10hWvUCuci3yec7=_4vXvNb5ypEVWJ9rwaTVpvLE_14w@mail.gmail.com>
Message-ID: <EA903C8B-1A1C-4EE8-8B41-B2FBD2CE52BD@redhat.com>


> On 24 Feb 2015, at 13:23, Sanne Grinovero <sanne at infinispan.org> wrote:
> 
> Interesting, so it seems it's possible to configure a specific cache
> for a specific entity?
> 
> I thought this was a pending limitation of the Infinispan Cache, and
> I'm afraid most other users will think it too as none of this is
> mentioned in the Hibernate documentation.

^ That's because this is an Infinispan specific detail and hence it's defined in the Infinispan 2LC configuration section, in the Infinispan user documentation.

> 
> 
> 
> On 24 February 2015 at 12:13, Dan Berindei <dan.berindei at gmail.com> wrote:
>> I believe the user guide has the answer to the original question:
>> 
>> http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_advanced_configuration_2
>> 
>>> On top of that, this finer grained cache definition enables users to define cache settings on a per entity/collection basis. For example:
>>> 
>>> <!-- If using JPA, add to your persistence.xml -->
>>> <property name="hibernate.cache.infinispan.com.acme.Person.cfg"
>>>   value="person-entity"/>
>>> <property name="hibernate.cache.infinispan.com.acme.Person.addresses.cfg"
>>>   value="addresses-collection"/>
>> 
>> 
>> I don't think the mapping can be changed at runtime, though.
>> 
>> 
>> Cheers
>> Dan
>> 
>> 
>> On Mon, Feb 23, 2015 at 7:23 PM, Sebastian ?askawiec
>> <sebastian.laskawiec at gmail.com> wrote:
>>> Hey!
>>> 
>>> I've noticed an interesting question on StackOverflow [1]. Is it possible to
>>> have 2 (or more) caches and associate database tables to specific caches? I
>>> can even imagine this question in broader perspective - is it possible to
>>> decide in the runtime, which cache should be used?
>>> 
>>> After a short discussion with Sanne we couldn't find any solution. Does
>>> anyone have any idea how to achieve this or maybe we have a "New Feature
>>> Request" candidate?
>>> 
>>> Thanks
>>> Sebastian
>>> 
>>> [1]
>>> http://stackoverflow.com/questions/28668971/hibernate-different-caches-for-different-tables
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarre?o
galder at redhat.com






From galder at redhat.com  Wed Feb 25 07:57:26 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Wed, 25 Feb 2015 13:57:26 +0100
Subject: [infinispan-dev] Different configuration with Hibernate
In-Reply-To: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>
References: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>
Message-ID: <7A22F9F0-0694-4B8D-868D-84236F5046ED@redhat.com>


> On 23 Feb 2015, at 18:23, Sebastian ?askawiec <sebastian.laskawiec at gmail.com> wrote:
> 
> Hey!
> 
> I've noticed an interesting question on StackOverflow [1]. Is it possible to have 2 (or more) caches and associate database tables to specific caches? I can even imagine this question in broader perspective - is it possible to decide in the runtime, which cache should be used? 
> 
> After a short discussion with Sanne we couldn't find any solution. Does anyone have any idea how to achieve this or maybe we have a "New Feature Request" candidate?

By default, each entity and collection is stored in its own cache. These caches are configured from a template cache. For entities, the template cache configuration is "entity" and for collections, "collection".

It is possible that users might want to use different cache configuration per entity and/or collection, e.g. for different expiration, lifespan settings and other potential changes. The most common thing to tweak is expiration, which is why we made these specific expiration changes easy to do.

However, if you want to change other things, like lifespan or max idle settings, you need to define your own cache configuration and then assign the cache name to the entity that you want.

All of this is explained in http://infinispan.org/docs/7.1.x/user_guide/user_guide.html#_advanced_configuration_2, including the different tweaks required in the property names when running inside Wildfly or EAP.

Cheers,

> 
> Thanks
> Sebastian
> 
> [1] http://stackoverflow.com/questions/28668971/hibernate-different-caches-for-different-tables
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarre?o
galder at redhat.com






From sebastian.laskawiec at gmail.com  Wed Feb 25 08:26:15 2015
From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=)
Date: Wed, 25 Feb 2015 13:26:15 +0000
Subject: [infinispan-dev] Different configuration with Hibernate
References: <CADP5VTUXGy-Qt5Ft3bSXNZ9dz7hbyzi=S79DmMNQeG6ZM7G=9g@mail.gmail.com>
	<7A22F9F0-0694-4B8D-868D-84236F5046ED@redhat.com>
Message-ID: <CADP5VTUV7orT4kWjZU2xHyfCFWg9LnVOWOBqvDpV9xniOCF-gA@mail.gmail.com>

Thanks for the explanation!

Thanks
Sebastian

?r., 25 lut 2015 o 14:01 u?ytkownik Galder Zamarre?o <galder at redhat.com>
napisa?:

>
> > On 23 Feb 2015, at 18:23, Sebastian ?askawiec <
> sebastian.laskawiec at gmail.com> wrote:
> >
> > Hey!
> >
> > I've noticed an interesting question on StackOverflow [1]. Is it
> possible to have 2 (or more) caches and associate database tables to
> specific caches? I can even imagine this question in broader perspective -
> is it possible to decide in the runtime, which cache should be used?
> >
> > After a short discussion with Sanne we couldn't find any solution. Does
> anyone have any idea how to achieve this or maybe we have a "New Feature
> Request" candidate?
>
> By default, each entity and collection is stored in its own cache. These
> caches are configured from a template cache. For entities, the template
> cache configuration is "entity" and for collections, "collection".
>
> It is possible that users might want to use different cache configuration
> per entity and/or collection, e.g. for different expiration, lifespan
> settings and other potential changes. The most common thing to tweak is
> expiration, which is why we made these specific expiration changes easy to
> do.
>
> However, if you want to change other things, like lifespan or max idle
> settings, you need to define your own cache configuration and then assign
> the cache name to the entity that you want.
>
> All of this is explained in http://infinispan.org/docs/7.
> 1.x/user_guide/user_guide.html#_advanced_configuration_2, including the
> different tweaks required in the property names when running inside Wildfly
> or EAP.
>
> Cheers,
>
> >
> > Thanks
> > Sebastian
> >
> > [1] http://stackoverflow.com/questions/28668971/hibernate-
> different-caches-for-different-tables
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarre?o
> galder at redhat.com
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150225/80a86515/attachment.html 

From galder at redhat.com  Thu Feb 26 03:57:16 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 26 Feb 2015 09:57:16 +0100
Subject: [infinispan-dev] org.infinispan.notifications.cachelistener.filter
	vs org.infinispan.filter
Message-ID: <A8598238-AA8E-4B97-9271-C02180AB704E@redhat.com>

Hey Will,

I wanted to ask you about the classes in org.infinispan.filter package.

I thought we agreed to get rid of these duplicate classes before 7.0.0.Final:
- org.infinispan.filter.Converter
- org.infinispan.filter.KeyValueFilter
- ... and related classes

The reason being that we pretty much had the same classes in org.infinispan.notifications.cachelistener.filter package.

Both set of classes were added in 7.0, so there's no reason why we should have left both sets around :|

These latter classes provide more information, but it can confuse users to decide which filters/converters to use where and how.

Am I missing something here?

We would not be able to remove anything now, but we should deprecate what should not be used.

>From a remote even perspective, only the org.infinispan.notifications.cachelistener.filter ones are relevant.

Cheers,
--
Galder Zamarre?o
galder at redhat.com






From dan.berindei at gmail.com  Thu Feb 26 05:06:06 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Thu, 26 Feb 2015 12:06:06 +0200
Subject: [infinispan-dev] NPE in SingleFileStore during node shutdown
In-Reply-To: <54EC868B.2010900@nexustelecom.com>
References: <54EC868B.2010900@nexustelecom.com>
Message-ID: <CA+nfvwRjznRDJ1Le8RPBGhjT0O6Qzy42mmtJtRpLz=4TA4yzvg@mail.gmail.com>

The rule of thumb is, if you see a NullPointerException, it's probably a bug :)

In this case, it looks like the purge thread started processing all
the entries in the store to see if they have expired, which is keeping
the CPU busy (and probably thrashing the disk as well - ISPN-5141
[1]). Stopping the cache didn't stop the purge thread, causing the
NPE. However, the exception should be harmless, and I wouldn't expect
the node to hang because of it.

On the other hand, SingleFileStore will not work properly with
shared=true. Unfortunately, it doesn't do anything to prevent you from
configuring it that way, but sharing the data file is not supported,
and it will cause data corruption.

Cheers
Dan

[1] https://issues.jboss.org/browse/ISPN-5141


On Tue, Feb 24, 2015 at 4:11 PM, Andreas Kruthoff
<andreas.kruthoff at nexustelecom.com> wrote:
> Hi Dev
>
>
>  From time to time, I'm running into this exception which causes the
> node to hang.
>
> Exception in thread "persistence-thread--p5-t1"
> org.infinispan.persistence.spi.PersistenceException:
> java.lang.NullPointerException
>         at
> org.infinispan.persistence.file.SingleFileStore$2.run(SingleFileStore.java:672)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>         at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
>         at
> org.infinispan.persistence.file.SingleFileStore.free(SingleFileStore.java:306)
>         at
> org.infinispan.persistence.file.SingleFileStore.access$1200(SingleFileStore.java:63)
>         at
> org.infinispan.persistence.file.SingleFileStore$2.run(SingleFileStore.java:670)
>         ... 3 more
>
>
> My scenario:
>
> Start 3 distributed nodes, owners="2", filestore with preload="true"
> shared="true" purge="false". About 20 Mio entries in the .dat file.
>
> The state-transfer takes about 5 Minutes, the cluster is ready
> afterwards, but still very busy operating on the filestore!
>
> If I stop a node now, the exception happens. If I wait for about 30
> Minutes (after the cpu load reduces), and the shutdown of a node works
> without problems. It persists its entries.
>
> Shall I create a JIRA or am I missing something?
>
> This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are prohibited from copying, disseminating or otherwise using the email or any attachment.
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From mudokonman at gmail.com  Thu Feb 26 09:12:39 2015
From: mudokonman at gmail.com (William Burns)
Date: Thu, 26 Feb 2015 09:12:39 -0500
Subject: [infinispan-dev]
 org.infinispan.notifications.cachelistener.filter vs org.infinispan.filter
In-Reply-To: <A8598238-AA8E-4B97-9271-C02180AB704E@redhat.com>
References: <A8598238-AA8E-4B97-9271-C02180AB704E@redhat.com>
Message-ID: <CA+YCuUMwFe9AvBbmcO7SQY-NrPq58Pgf6ogTahkgj5=dj1h9Cw@mail.gmail.com>

On Thu, Feb 26, 2015 at 3:57 AM, Galder Zamarre?o <galder at redhat.com> wrote:
> Hey Will,
>
> I wanted to ask you about the classes in org.infinispan.filter package.
>
> I thought we agreed to get rid of these duplicate classes before 7.0.0.Final:
> - org.infinispan.filter.Converter
> - org.infinispan.filter.KeyValueFilter
> - ... and related classes
>
> The reason being that we pretty much had the same classes in org.infinispan.notifications.cachelistener.filter package.

I agree they are very similar.

>
> Both set of classes were added in 7.0, so there's no reason why we should have left both sets around :|

Each one fulfills a different purpose.  Originally only the 1 set of
classes was used, but event filters evolved to have new requirements
(oldValue, oldMetadata, retry, event type) that don't make sense for
normal filtering.  The regular KeyValueFilter, KeyFilter, Converter
classes are still used when filtering existing entries (CacheLoader,
EntryIterator).  Also the simpler filter & converter will be able to
be used as stepping stones for Streams when we move to Java 8
(although a tweak to the interface(s) will probably be required).

>
> These latter classes provide more information, but it can confuse users to decide which filters/converters to use where and how.

The CacheEventFilter/CacheEventFilterConverter are only used when
using events.  The other simpler filters are used in all other cases..

>
> Am I missing something here?

The classes we talked about removing were the *Factory classes for the
various filters.  We can discuss converging the ones you mentioned
here, but IMO the provided functionality has diverged quite a bit,
which would make having a consistent API very ugly for one or both of
the use cases.

>
> We would not be able to remove anything now, but we should deprecate what should not be used.
>
> From a remote even perspective, only the org.infinispan.notifications.cachelistener.filter ones are relevant.

I would say from a remote event perspective you are correct.  However
once we add entry iteration for remote, we would want to use the more
simplified interfaces.

>
> Cheers,
> --
> Galder Zamarre?o
> galder at redhat.com
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From rory.odonnell at oracle.com  Fri Feb 27 06:02:53 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 27 Feb 2015 11:02:53 +0000
Subject: [infinispan-dev] Early Access builds for JDK 9 b51 are available on
	java.net
Message-ID: <54F04EDD.80209@oracle.com>


Hi Galder,

Early Access build for JDK 9 b51 <https://jdk9.java.net/download/> 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/jdk9/changes/jdk9-b51.html>

I'd also like to use this opportunity to point you to JEP 238: 
Multi-Version JAR Files [0],
which is currently a Candidate JEP for JDK 9.

It's goal is to extend the JAR file format to allow multiple, JDK 
release-specific versions of class
files to coexist in a single file. An additional goal is to backport the 
run-time changes to
JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a 
detailed discussion,
please see the corresponding thread on the core-libs-dev mailing list. [1]

Please keep in mind that a JEP in the Candidate state is merely an idea 
worthy of consideration
by JDK Release Projects and related efforts; there is no commitment that 
it will be delivered in
any particular release.

Comments, questions, and suggestions are welcome on the corelibs-dev 
mailing list. (If you
haven?t already subscribed to that list then please do so first, 
otherwise your message will be
discarded as spam.)

Rgds,Rory

[0] http://openjdk.java.net/jeps/238
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031461.html 


-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150227/f9a434b5/attachment.html 

From rvansa at redhat.com  Fri Feb 27 09:49:35 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 27 Feb 2015 15:49:35 +0100
Subject: [infinispan-dev] CacheEntry vs. Metadata
Message-ID: <54F083FF.9000802@redhat.com>

Hi,

I was already several times looking on the class hierarchy of CacheEntry 
and its descendants. Since the documentation of those interfaces is 
usually a one liner, I'd like to ask for the big picture:

So we have CacheEntry, which implements MetadataAware - therefore, it 
contains a metadata, which define lifespan, maxIdle time and version. 
However, even the CacheEntry interface itself contains getters for 
lifespan and idle time and MortalCacheEntry hosts the fields - so I see 
that there's some duplication with the Metadata object.
Beyond the expiration-related stuff (and common key - value getters), 
CacheEntry has several methods querying and manipulating its state - 
isChanged, isValid, isRemoved etc. It's a bit confusing that this is 
presented not as a single state but rather a matrix of boolean states. 
When I've tried to implement EntryProcessor several weeks ago (I've 
stopped the attempts since this should be implemented in Infinispan 8), 
I had quite a hard time figuring out which should be set and how in case 
I want to update/remove the entry. undelete() and skipLookup() are not 
obvious, either.

Is the reason for having Immortal/Mortal/Transient/TransientMortal 
entries + Metadata* versions + *Values to optimally use memory?

Then there are the ReadCommitted and RepeatableRead entries - are these 
ever stored in data container, or just in context? What's the exact 
relation between those implementing InternalCacheEntry and MVCCEntry?

Then there's the DeltaAwareCacheEntry - this does not fit to the image 
for me at all.

I am also not sure about the relation of EmbeddedMetadata and 
InternalMetadataImpl

Thanks for your insight!

Radim


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team