From galder at redhat.com  Thu Oct  1 09:33:11 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 1 Oct 2015 15:33:11 +0200
Subject: [infinispan-dev] Lambda's & Batching
In-Reply-To: <CAFm4XO05SfJ=4HipFSKX_0MsFm8aTudVcmtbT5vHXxFuR9+H9w@mail.gmail.com>
References: <CAFm4XO05SfJ=4HipFSKX_0MsFm8aTudVcmtbT5vHXxFuR9+H9w@mail.gmail.com>
Message-ID: <49DEF5DC-0F3E-4B4C-91F1-7F0071E1A1CA@redhat.com>

Replies inline:

> On 1 Oct 2015, at 00:16, Sanne Grinovero <sanne at infinispan.org> wrote:
> 
> A local cache with batching enabled produces this:
> 
> java.lang.IllegalArgumentException: Cannot create a transactional
> context without a valid Transaction instance.
> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69)
> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
> at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60)
> (<-- experimental uncommitted code here)
> 
> 
> I'm guessing the eval implementations is needing the
> "auto-transaction-start" semantics which we normally have for other
> operations in a batching cache... right?
> 
> But I wonder about the usefulness of having a short lived batching
> context when all I'm doing is sending a lambda to a specific entry:
> wouldn't it be even better to treat this as a no-context operation?

I agree, if no transaction is in context, it'd be better to treat it as single operation context. 

I'll add a JIRA and address it.

Cheers,

> 
> Thanks,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From galder at redhat.com  Thu Oct  1 09:37:51 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 1 Oct 2015 15:37:51 +0200
Subject: [infinispan-dev] Lambda's & Batching
In-Reply-To: <49DEF5DC-0F3E-4B4C-91F1-7F0071E1A1CA@redhat.com>
References: <CAFm4XO05SfJ=4HipFSKX_0MsFm8aTudVcmtbT5vHXxFuR9+H9w@mail.gmail.com>
	<49DEF5DC-0F3E-4B4C-91F1-7F0071E1A1CA@redhat.com>
Message-ID: <A9BC9F67-2776-4093-B39E-67D6B728E104@redhat.com>

https://issues.jboss.org/browse/ISPN-5806

--
Galder Zamarre?o
Infinispan, Red Hat

> On 1 Oct 2015, at 15:33, Galder Zamarre?o <galder at redhat.com> wrote:
> 
> Replies inline:
> 
>> On 1 Oct 2015, at 00:16, Sanne Grinovero <sanne at infinispan.org> wrote:
>> 
>> A local cache with batching enabled produces this:
>> 
>> java.lang.IllegalArgumentException: Cannot create a transactional
>> context without a valid Transaction instance.
>> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69)
>> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
>> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
>> at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60)
>> (<-- experimental uncommitted code here)
>> 
>> 
>> I'm guessing the eval implementations is needing the
>> "auto-transaction-start" semantics which we normally have for other
>> operations in a batching cache... right?
>> 
>> But I wonder about the usefulness of having a short lived batching
>> context when all I'm doing is sending a lambda to a specific entry:
>> wouldn't it be even better to treat this as a no-context operation?
> 
> I agree, if no transaction is in context, it'd be better to treat it as single operation context. 
> 
> I'll add a JIRA and address it.
> 
> Cheers,
> 
>> 
>> Thanks,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From sanne at infinispan.org  Thu Oct  1 10:36:49 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 1 Oct 2015 16:36:49 +0200
Subject: [infinispan-dev] Lambda's & Batching
In-Reply-To: <A9BC9F67-2776-4093-B39E-67D6B728E104@redhat.com>
References: <CAFm4XO05SfJ=4HipFSKX_0MsFm8aTudVcmtbT5vHXxFuR9+H9w@mail.gmail.com>
	<49DEF5DC-0F3E-4B4C-91F1-7F0071E1A1CA@redhat.com>
	<A9BC9F67-2776-4093-B39E-67D6B728E104@redhat.com>
Message-ID: <CAFm4XO15kYufUg8=cu=D9K0ybmM5dRcmiruYnf-5SokC+m+fzQ@mail.gmail.com>

Thanks!

On 1 October 2015 at 15:37, Galder Zamarre?o <galder at redhat.com> wrote:
> https://issues.jboss.org/browse/ISPN-5806
>
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>> On 1 Oct 2015, at 15:33, Galder Zamarre?o <galder at redhat.com> wrote:
>>
>> Replies inline:
>>
>>> On 1 Oct 2015, at 00:16, Sanne Grinovero <sanne at infinispan.org> wrote:
>>>
>>> A local cache with batching enabled produces this:
>>>
>>> java.lang.IllegalArgumentException: Cannot create a transactional
>>> context without a valid Transaction instance.
>>> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69)
>>> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
>>> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
>>> at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60)
>>> (<-- experimental uncommitted code here)
>>>
>>>
>>> I'm guessing the eval implementations is needing the
>>> "auto-transaction-start" semantics which we normally have for other
>>> operations in a batching cache... right?
>>>
>>> But I wonder about the usefulness of having a short lived batching
>>> context when all I'm doing is sending a lambda to a specific entry:
>>> wouldn't it be even better to treat this as a no-context operation?
>>
>> I agree, if no transaction is in context, it'd be better to treat it as single operation context.
>>
>> I'll add a JIRA and address it.
>>
>> Cheers,
>>
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> 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 dan.berindei at gmail.com  Mon Oct  5 02:34:14 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Mon, 5 Oct 2015 09:34:14 +0300
Subject: [infinispan-dev] Cache entry creation and modification events
Message-ID: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>

Hi guys

We have two different listener types for cache entry creation
(@CacheEntryCreated) and modification (of an already-existing entry,
@CacheEntryModified). However, PutMapCommand and
PutKeyValueCommand/IGNORE_RETURN_VALUES do not read the previous value
from loaders and/or remote nodes, so we sometimes notify the
@CacheEntryCreated listeners instead of the @CacheEntryModified
listeners.

PutMapCommand has a "workaround" for this: it also notifies the
@CacheEntryModified listener, regardless of whether it found the entry
or not. I'd like to change this [1] and make PutMapCommand and
PutKeyValueCommand behave the same way.

These are the options I'm considering:

1. Replicate the PutKeyValueCommand behaviour, and document that we
may sometimes notify the @CacheEntryCreated listener even though the
entry already exists.
It would be the simplest to implement (in fact I already have a
patch), but it doesn't feel right.

2. Always read the previous value from loaders and/or remote nodes
when a @CacheEntryCreated/Modified event listener is registered.
This would give us the correct behaviour, at the expense of performance.

3. Same as option 2, but also add a @CacheEntryWritten listener type,
which only receives the new value and is notified regardless of
whether the entry was created or modified.
This would give users a choice: if they don't care about the previous
value, the cache will be just as fast as usual, but if they need the
previous value, they need to accept a slowdown.

4. Add the @CacheEntryWritten listener type, but only notify these
listeners instead of the @CacheEntryCreated/Modified listeners for
cache.putAll() and cache.withFlags(IGNORE_RETURN_VALUES).put().
This is the option Galder chose for the functional API, but the
difference between write-only and read-write operations is a lot
clearer there, so I'm not convinced it's ok for the ConcurrentMap API.


Personally I would choose option 3, because it would be mostly
backwards-compatible: old code would only need to change if existing
listeners are slowing down the cache.

Cheers
Dan

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

From ttarrant at redhat.com  Mon Oct  5 04:36:58 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 5 Oct 2015 04:36:58 -0400 (EDT)
Subject: [infinispan-dev] Data container resizing
Message-ID: <8c0f9a7e-1e9b-4c24-9ffc-35b52ed3eeeb@redhat.com>


Hi all,
Sebastian recently added BCHMV8 resizing and I'm now hooking it up to configuratiombean ?jmx and server. I wanted your opinion on some details.?

- configuration: easy, register a listener with the attribute so that invoking configuration.eviction().size (newSize) does a resize of the data container?
- server already exposes the size in the management model, ?we just need to change its behaviour so that the change is "live". In this context the change is also persisted to the xml configuration?
- Jmx: do we want a writable "capacity" attribute or a resize operation? And do we want it on the cache mbean or on a new data container mbean? And should the change affect the configuration object too, i.e. invoking configuration.eviction().size () should return the new value? For symmetry with server we should.?

Tristan

--
Tristan Tarrant?
Infinispan Lead?
JBoss a division of Red Hat?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20151005/d887c5c9/attachment-0001.html 

From dan.berindei at gmail.com  Mon Oct  5 10:42:20 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Mon, 5 Oct 2015 17:42:20 +0300
Subject: [infinispan-dev] Weekly IRC meeting minutes 2015-10-05
Message-ID: <CA+nfvwQAMQfKL+pKM9m1SL9p1vGa4w5qT7bWf7heGS1oNuvPZQ@mail.gmail.com>

Hi everyone

Here's the transcript for today's IRC meeting:

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2015/infinispan.2015-10-05-14.25.log.html

Cheers
Dan

From galder at redhat.com  Tue Oct  6 04:17:53 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 6 Oct 2015 09:17:53 +0100
Subject: [infinispan-dev] Smoke Testsuite wiki
Message-ID: <B9EF5641-9623-45D3-B42C-C5B467ED42C9@redhat.com>

Hi all,

I've written a wiki with some of the days we discussed last week about having a Smoke Testsuite.

Feel free to comment.

Cheers,

[1] https://github.com/infinispan/infinispan/wiki/Smoke-Testsuite
--
Galder Zamarre?o
Infinispan, Red Hat



From slaskawi at redhat.com  Tue Oct  6 07:13:59 2015
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 6 Oct 2015 13:13:59 +0200
Subject: [infinispan-dev] Data container resizing
In-Reply-To: <8c0f9a7e-1e9b-4c24-9ffc-35b52ed3eeeb@redhat.com>
References: <8c0f9a7e-1e9b-4c24-9ffc-35b52ed3eeeb@redhat.com>
Message-ID: <CAA9R9O7Ve2Ztx4XUsxX4TYQTHFBYXjm3BcjNYehKixtttKUa_g@mail.gmail.com>

Hey Tristan!

See comments inlined.

Thanks
Sebastian

On Mon, Oct 5, 2015 at 10:36 AM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> - configuration: easy, register a listener with the attribute so that
> invoking configuration.eviction().size (newSize) does a resize of the data
> container
>

+1, looks like a simple solution that might do the job.


> - server already exposes the size in the management model,  we just need
> to change its behaviour so that the change is "live". In this context the
> change is also persisted to the xml configuration
>

+1, I like this approach however it may confuse our users a little bit.
Maybe we should have a flag in configuration (disabled by default) which
would enable persisting changes back into xml?


> - Jmx: do we want a writable "capacity" attribute or a resize operation?
> And do we want it on the cache mbean or on a new data container mbean? And
> should the change affect the configuration object too, i.e. invoking
> configuration.eviction().size () should return the new value? For symmetry
> with server we should.
>

+1 for writable attribute. This would fix nicely into configuration
listeners. How about exposing new Configuration MBean with all writable
configuration attributes?
+1 for staying symmetric with our solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20151006/93521464/attachment.html 

From ttarrant at redhat.com  Tue Oct  6 07:51:41 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Tue, 6 Oct 2015 13:51:41 +0200
Subject: [infinispan-dev] Data container resizing
In-Reply-To: <CAA9R9O7Ve2Ztx4XUsxX4TYQTHFBYXjm3BcjNYehKixtttKUa_g@mail.gmail.com>
References: <8c0f9a7e-1e9b-4c24-9ffc-35b52ed3eeeb@redhat.com>
	<CAA9R9O7Ve2Ztx4XUsxX4TYQTHFBYXjm3BcjNYehKixtttKUa_g@mail.gmail.com>
Message-ID: <5613B5CD.6010203@redhat.com>

On 06/10/2015 13:13, Sebastian Laskawiec wrote:

> +1, I like this approach however it may confuse our users a little bit.
> Maybe we should have a flag in configuration (disabled by default) which
> would enable persisting changes back into xml?

No, this would go against the WildFly model of doing things. What can be 
done is to create a special attribute set to RUNTIME_ONLY, but I'm not 
sure I like this.

>
>     - Jmx: do we want a writable "capacity" attribute or a resize
>     operation? And do we want it on the cache mbean or on a new data
>     container mbean? And should the change affect the configuration
>     object too, i.e. invoking configuration.eviction().size () should
>     return the new value? For symmetry with server we should.
>
>
> +1 for writable attribute. This would fix nicely into configuration
> listeners. How about exposing new Configuration MBean with all writable
> configuration attributes?

Ideally it would be nice to replicate the same tree structure of the 
server configuration model (which also mimics the programmatic API), so 
that each cache trait has its own MBean. This would mean for example 
having an Eviction MBean as a child of the Cache MBean.

Tristan

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

From galder at redhat.com  Thu Oct  8 06:37:54 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 8 Oct 2015 11:37:54 +0100
Subject: [infinispan-dev] Cache entry creation and modification events
In-Reply-To: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
References: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
Message-ID: <5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>

I think I'm leaning towards 3.

I would favour 2 if all listeners were already in place for Functional API, since I think down the line we'd want to offer 3 map-like APIs: ConcurrentMap, JCache and Functional Map. Hence phasing out Cache as an end-user API... Since we're not there yet, I'd vote for option 3 below.

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat

> On 5 Oct 2015, at 07:34, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
> Hi guys
> 
> We have two different listener types for cache entry creation
> (@CacheEntryCreated) and modification (of an already-existing entry,
> @CacheEntryModified). However, PutMapCommand and
> PutKeyValueCommand/IGNORE_RETURN_VALUES do not read the previous value
> from loaders and/or remote nodes, so we sometimes notify the
> @CacheEntryCreated listeners instead of the @CacheEntryModified
> listeners.
> 
> PutMapCommand has a "workaround" for this: it also notifies the
> @CacheEntryModified listener, regardless of whether it found the entry
> or not. I'd like to change this [1] and make PutMapCommand and
> PutKeyValueCommand behave the same way.
> 
> These are the options I'm considering:
> 
> 1. Replicate the PutKeyValueCommand behaviour, and document that we
> may sometimes notify the @CacheEntryCreated listener even though the
> entry already exists.
> It would be the simplest to implement (in fact I already have a
> patch), but it doesn't feel right.
> 
> 2. Always read the previous value from loaders and/or remote nodes
> when a @CacheEntryCreated/Modified event listener is registered.
> This would give us the correct behaviour, at the expense of performance.
> 
> 3. Same as option 2, but also add a @CacheEntryWritten listener type,
> which only receives the new value and is notified regardless of
> whether the entry was created or modified.
> This would give users a choice: if they don't care about the previous
> value, the cache will be just as fast as usual, but if they need the
> previous value, they need to accept a slowdown.
> 
> 4. Add the @CacheEntryWritten listener type, but only notify these
> listeners instead of the @CacheEntryCreated/Modified listeners for
> cache.putAll() and cache.withFlags(IGNORE_RETURN_VALUES).put().
> This is the option Galder chose for the functional API, but the
> difference between write-only and read-write operations is a lot
> clearer there, so I'm not convinced it's ok for the ConcurrentMap API.
> 
> 
> Personally I would choose option 3, because it would be mostly
> backwards-compatible: old code would only need to change if existing
> listeners are slowing down the cache.
> 
> Cheers
> Dan
> 
> [1] https://issues.jboss.org/browse/ISPN-5752
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From galder at redhat.com  Thu Oct  8 06:49:51 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 8 Oct 2015 11:49:51 +0100
Subject: [infinispan-dev] Data container resizing
In-Reply-To: <8c0f9a7e-1e9b-4c24-9ffc-35b52ed3eeeb@redhat.com>
References: <8c0f9a7e-1e9b-4c24-9ffc-35b52ed3eeeb@redhat.com>
Message-ID: <0ECF10AE-D37D-45B3-ADD1-6C20BDACD49D@redhat.com>



--
Galder Zamarre?o
Infinispan, Red Hat

> On 5 Oct 2015, at 09:36, Tristan Tarrant <ttarrant at redhat.com> wrote:
> 
> 
> Hi all,
> Sebastian recently added BCHMV8 resizing and I'm now hooking it up to configuratiombean  jmx and server. I wanted your opinion on some details. 
> 
> - configuration: easy, register a listener with the attribute so that invoking configuration.eviction().size (newSize) does a resize of the data container 
> - server already exposes the size in the management model,  we just need to change its behaviour so that the change is "live". In this context the change is also persisted to the xml configuration 
> - Jmx: do we want a writable "capacity" attribute or a resize operation? And do we want it on the cache mbean or on a new data container mbean? And should the change affect the configuration object too, i.e. invoking configuration.eviction().size () should return the new value? For symmetry with server we should. 

I'd add it to the cache mbean.

My first impression is that the configured value should change too.

Cheers,

> 
> 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



From mudokonman at gmail.com  Thu Oct  8 11:06:43 2015
From: mudokonman at gmail.com (William Burns)
Date: Thu, 08 Oct 2015 15:06:43 +0000
Subject: [infinispan-dev] Cache entry creation and modification events
In-Reply-To: <5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>
References: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
	<5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>
Message-ID: <CA+YCuUNmsUe7FPFgWqa1TBYcoDHh_-c_c556rWO2PYZhM-47eg@mail.gmail.com>

I also like #3.  However I wonder if we want to expand it to include cache
removal/expiration in this new event as well.  This would simplify a user
listening for data being changed in only a given listener and it could be
clustered.

 - Will

On Thu, Oct 8, 2015 at 6:38 AM Galder Zamarre?o <galder at redhat.com> wrote:

> I think I'm leaning towards 3.
>
> I would favour 2 if all listeners were already in place for Functional
> API, since I think down the line we'd want to offer 3 map-like APIs:
> ConcurrentMap, JCache and Functional Map. Hence phasing out Cache as an
> end-user API... Since we're not there yet, I'd vote for option 3 below.
>
> Cheers,
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
> > On 5 Oct 2015, at 07:34, Dan Berindei <dan.berindei at gmail.com> wrote:
> >
> > Hi guys
> >
> > We have two different listener types for cache entry creation
> > (@CacheEntryCreated) and modification (of an already-existing entry,
> > @CacheEntryModified). However, PutMapCommand and
> > PutKeyValueCommand/IGNORE_RETURN_VALUES do not read the previous value
> > from loaders and/or remote nodes, so we sometimes notify the
> > @CacheEntryCreated listeners instead of the @CacheEntryModified
> > listeners.
> >
> > PutMapCommand has a "workaround" for this: it also notifies the
> > @CacheEntryModified listener, regardless of whether it found the entry
> > or not. I'd like to change this [1] and make PutMapCommand and
> > PutKeyValueCommand behave the same way.
> >
> > These are the options I'm considering:
> >
> > 1. Replicate the PutKeyValueCommand behaviour, and document that we
> > may sometimes notify the @CacheEntryCreated listener even though the
> > entry already exists.
> > It would be the simplest to implement (in fact I already have a
> > patch), but it doesn't feel right.
> >
> > 2. Always read the previous value from loaders and/or remote nodes
> > when a @CacheEntryCreated/Modified event listener is registered.
> > This would give us the correct behaviour, at the expense of performance.
> >
> > 3. Same as option 2, but also add a @CacheEntryWritten listener type,
> > which only receives the new value and is notified regardless of
> > whether the entry was created or modified.
> > This would give users a choice: if they don't care about the previous
> > value, the cache will be just as fast as usual, but if they need the
> > previous value, they need to accept a slowdown.
> >
> > 4. Add the @CacheEntryWritten listener type, but only notify these
> > listeners instead of the @CacheEntryCreated/Modified listeners for
> > cache.putAll() and cache.withFlags(IGNORE_RETURN_VALUES).put().
> > This is the option Galder chose for the functional API, but the
> > difference between write-only and read-write operations is a lot
> > clearer there, so I'm not convinced it's ok for the ConcurrentMap API.
> >
> >
> > Personally I would choose option 3, because it would be mostly
> > backwards-compatible: old code would only need to change if existing
> > listeners are slowing down the cache.
> >
> > Cheers
> > Dan
> >
> > [1] https://issues.jboss.org/browse/ISPN-5752
> > _______________________________________________
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20151008/6ca339e0/attachment-0001.html 

From dan.berindei at gmail.com  Thu Oct  8 12:38:35 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Thu, 8 Oct 2015 19:38:35 +0300
Subject: [infinispan-dev] Cache entry creation and modification events
In-Reply-To: <CA+YCuUNmsUe7FPFgWqa1TBYcoDHh_-c_c556rWO2PYZhM-47eg@mail.gmail.com>
References: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
	<5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>
	<CA+YCuUNmsUe7FPFgWqa1TBYcoDHh_-c_c556rWO2PYZhM-47eg@mail.gmail.com>
Message-ID: <CA+nfvwSyTZe4aAWhDnXwQ_t0n6LePoWmtgV3LrJ9PtJvhPUthg@mail.gmail.com>

I'm not sure about including removals/invalidations/expiration,
because there would be no way to say "I want to be notified on
creation and modification, but no removals". On the other hand, adding
3 more methods delegating to the same implementation, while not
pretty, does allow you to listen to all changes.

Or are you thinking that the 3 additional listeners would add
significant overhead when clustered?

Cheers
Dan


On Thu, Oct 8, 2015 at 6:06 PM, William Burns <mudokonman at gmail.com> wrote:
> I also like #3.  However I wonder if we want to expand it to include cache
> removal/expiration in this new event as well.  This would simplify a user
> listening for data being changed in only a given listener and it could be
> clustered.
>
>  - Will
>
> On Thu, Oct 8, 2015 at 6:38 AM Galder Zamarre?o <galder at redhat.com> wrote:
>>
>> I think I'm leaning towards 3.
>>
>> I would favour 2 if all listeners were already in place for Functional
>> API, since I think down the line we'd want to offer 3 map-like APIs:
>> ConcurrentMap, JCache and Functional Map. Hence phasing out Cache as an
>> end-user API... Since we're not there yet, I'd vote for option 3 below.
>>
>> Cheers,
>> --
>> Galder Zamarre?o
>> Infinispan, Red Hat
>>
>> > On 5 Oct 2015, at 07:34, Dan Berindei <dan.berindei at gmail.com> wrote:
>> >
>> > Hi guys
>> >
>> > We have two different listener types for cache entry creation
>> > (@CacheEntryCreated) and modification (of an already-existing entry,
>> > @CacheEntryModified). However, PutMapCommand and
>> > PutKeyValueCommand/IGNORE_RETURN_VALUES do not read the previous value
>> > from loaders and/or remote nodes, so we sometimes notify the
>> > @CacheEntryCreated listeners instead of the @CacheEntryModified
>> > listeners.
>> >
>> > PutMapCommand has a "workaround" for this: it also notifies the
>> > @CacheEntryModified listener, regardless of whether it found the entry
>> > or not. I'd like to change this [1] and make PutMapCommand and
>> > PutKeyValueCommand behave the same way.
>> >
>> > These are the options I'm considering:
>> >
>> > 1. Replicate the PutKeyValueCommand behaviour, and document that we
>> > may sometimes notify the @CacheEntryCreated listener even though the
>> > entry already exists.
>> > It would be the simplest to implement (in fact I already have a
>> > patch), but it doesn't feel right.
>> >
>> > 2. Always read the previous value from loaders and/or remote nodes
>> > when a @CacheEntryCreated/Modified event listener is registered.
>> > This would give us the correct behaviour, at the expense of performance.
>> >
>> > 3. Same as option 2, but also add a @CacheEntryWritten listener type,
>> > which only receives the new value and is notified regardless of
>> > whether the entry was created or modified.
>> > This would give users a choice: if they don't care about the previous
>> > value, the cache will be just as fast as usual, but if they need the
>> > previous value, they need to accept a slowdown.
>> >
>> > 4. Add the @CacheEntryWritten listener type, but only notify these
>> > listeners instead of the @CacheEntryCreated/Modified listeners for
>> > cache.putAll() and cache.withFlags(IGNORE_RETURN_VALUES).put().
>> > This is the option Galder chose for the functional API, but the
>> > difference between write-only and read-write operations is a lot
>> > clearer there, so I'm not convinced it's ok for the ConcurrentMap API.
>> >
>> >
>> > Personally I would choose option 3, because it would be mostly
>> > backwards-compatible: old code would only need to change if existing
>> > listeners are slowing down the cache.
>> >
>> > Cheers
>> > Dan
>> >
>> > [1] https://issues.jboss.org/browse/ISPN-5752
>> > _______________________________________________
>> > 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


From rory.odonnell at oracle.com  Fri Oct  9 04:36:43 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 9 Oct 2015 09:36:43 +0100
Subject: [infinispan-dev] Early Access build 83 for JDK 9 and JDK 9 with
 Project Jigsaw are available for download.
Message-ID: <56177C9B.8050202@oracle.com>


Hi Galder,

JDK 9 with Project Jigsaw Early Access build b83 is available for 
download at jdk9.java.net/jigsaw <http://jdk9.java.net/jigsaw>.

Notable changes:

  * The -Xoverride option has been extended and renamed to -Xpatch, and
    the -XaddReads option has been restored [1] (changesets
    04dd0430530e, 095fc622bf01).
  * ClassLoader::getPackage now works as it did previously, walking the
    class-loader hierarchy in order to find Package objects, which
    enables NetBeans to start up [2] (5805781b9370).
  * Class::getResource will now return a URL to a resource in a module,
    when invoked from code within that module (0fbe4c72638a).
  * The big module-summary table has been improved, and will now be
    posted with each build [3] (e922b207c170).


JDK 9 Early Access build b83 is available for download 
<https://jdk9.java.net/download/> , summary of  changes are listed here 
<http://download.java.net/jdk9/changes/jdk9-b78.html?q=download/jdk9/changes/jdk9-b83.html>.

  * Request for G1 GC Feedback at wiki -
    https://wiki.openjdk.java.net/display/HotSpot/G1GC+Feedback
  * This wiki-page aims to outline the basic JVM parameters switching to
    G1GC, and how you can help collecting data comparing the G1GC and
    Parallel GC.

Rgds, Rory

[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004740.html
[2]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004730.html
[3]http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.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/20151009/1162fce8/attachment.html 

From mudokonman at gmail.com  Fri Oct  9 09:39:19 2015
From: mudokonman at gmail.com (William Burns)
Date: Fri, 09 Oct 2015 13:39:19 +0000
Subject: [infinispan-dev] Cache entry creation and modification events
In-Reply-To: <CA+nfvwSyTZe4aAWhDnXwQ_t0n6LePoWmtgV3LrJ9PtJvhPUthg@mail.gmail.com>
References: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
	<5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>
	<CA+YCuUNmsUe7FPFgWqa1TBYcoDHh_-c_c556rWO2PYZhM-47eg@mail.gmail.com>
	<CA+nfvwSyTZe4aAWhDnXwQ_t0n6LePoWmtgV3LrJ9PtJvhPUthg@mail.gmail.com>
Message-ID: <CA+YCuUNqNvTkrF6UB32BvViQG9o_-zpZ1z4EdEtOt1B3WMj-JQ@mail.gmail.com>

On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei at gmail.com> wrote:

> I'm not sure about including removals/invalidations/expiration,
>

Invalidations to me don't quite fit, since it should be passivated in that
case.


> because there would be no way to say "I want to be notified on
> creation and modification, but no removals". On the other hand, adding
>

We could always add a parameter to the new annotation to say if you don't
care about removals maybe?


> 3 more methods delegating to the same implementation, while not
> pretty, does allow you to listen to all changes.
>

Do we need 3 methods?  Yes I think it would be nice for people.


>
> Or are you thinking that the 3 additional listeners would add
> significant overhead when clustered?
>

I was thinking it would be 1 listener.  CacheNotifierImpl could raise the
new event in addition to the existing ones.


>
> Cheers
> Dan
>
>
> On Thu, Oct 8, 2015 at 6:06 PM, William Burns <mudokonman at gmail.com>
> wrote:
> > I also like #3.  However I wonder if we want to expand it to include
> cache
> > removal/expiration in this new event as well.  This would simplify a user
> > listening for data being changed in only a given listener and it could be
> > clustered.
> >
> >  - Will
> >
> > On Thu, Oct 8, 2015 at 6:38 AM Galder Zamarre?o <galder at redhat.com>
> wrote:
> >>
> >> I think I'm leaning towards 3.
> >>
> >> I would favour 2 if all listeners were already in place for Functional
> >> API, since I think down the line we'd want to offer 3 map-like APIs:
> >> ConcurrentMap, JCache and Functional Map. Hence phasing out Cache as an
> >> end-user API... Since we're not there yet, I'd vote for option 3 below.
> >>
> >> Cheers,
> >> --
> >> Galder Zamarre?o
> >> Infinispan, Red Hat
> >>
> >> > On 5 Oct 2015, at 07:34, Dan Berindei <dan.berindei at gmail.com> wrote:
> >> >
> >> > Hi guys
> >> >
> >> > We have two different listener types for cache entry creation
> >> > (@CacheEntryCreated) and modification (of an already-existing entry,
> >> > @CacheEntryModified). However, PutMapCommand and
> >> > PutKeyValueCommand/IGNORE_RETURN_VALUES do not read the previous value
> >> > from loaders and/or remote nodes, so we sometimes notify the
> >> > @CacheEntryCreated listeners instead of the @CacheEntryModified
> >> > listeners.
> >> >
> >> > PutMapCommand has a "workaround" for this: it also notifies the
> >> > @CacheEntryModified listener, regardless of whether it found the entry
> >> > or not. I'd like to change this [1] and make PutMapCommand and
> >> > PutKeyValueCommand behave the same way.
> >> >
> >> > These are the options I'm considering:
> >> >
> >> > 1. Replicate the PutKeyValueCommand behaviour, and document that we
> >> > may sometimes notify the @CacheEntryCreated listener even though the
> >> > entry already exists.
> >> > It would be the simplest to implement (in fact I already have a
> >> > patch), but it doesn't feel right.
> >> >
> >> > 2. Always read the previous value from loaders and/or remote nodes
> >> > when a @CacheEntryCreated/Modified event listener is registered.
> >> > This would give us the correct behaviour, at the expense of
> performance.
> >> >
> >> > 3. Same as option 2, but also add a @CacheEntryWritten listener type,
> >> > which only receives the new value and is notified regardless of
> >> > whether the entry was created or modified.
> >> > This would give users a choice: if they don't care about the previous
> >> > value, the cache will be just as fast as usual, but if they need the
> >> > previous value, they need to accept a slowdown.
> >> >
> >> > 4. Add the @CacheEntryWritten listener type, but only notify these
> >> > listeners instead of the @CacheEntryCreated/Modified listeners for
> >> > cache.putAll() and cache.withFlags(IGNORE_RETURN_VALUES).put().
> >> > This is the option Galder chose for the functional API, but the
> >> > difference between write-only and read-write operations is a lot
> >> > clearer there, so I'm not convinced it's ok for the ConcurrentMap API.
> >> >
> >> >
> >> > Personally I would choose option 3, because it would be mostly
> >> > backwards-compatible: old code would only need to change if existing
> >> > listeners are slowing down the cache.
> >> >
> >> > Cheers
> >> > Dan
> >> >
> >> > [1] https://issues.jboss.org/browse/ISPN-5752
> >> > _______________________________________________
> >> > 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
>
> _______________________________________________
> 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/20151009/24e55d2c/attachment.html 

From dan.berindei at gmail.com  Mon Oct 12 04:02:17 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Mon, 12 Oct 2015 11:02:17 +0300
Subject: [infinispan-dev] Cache entry creation and modification events
In-Reply-To: <CA+YCuUNqNvTkrF6UB32BvViQG9o_-zpZ1z4EdEtOt1B3WMj-JQ@mail.gmail.com>
References: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
	<5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>
	<CA+YCuUNmsUe7FPFgWqa1TBYcoDHh_-c_c556rWO2PYZhM-47eg@mail.gmail.com>
	<CA+nfvwSyTZe4aAWhDnXwQ_t0n6LePoWmtgV3LrJ9PtJvhPUthg@mail.gmail.com>
	<CA+YCuUNqNvTkrF6UB32BvViQG9o_-zpZ1z4EdEtOt1B3WMj-JQ@mail.gmail.com>
Message-ID: <CA+nfvwSUzU6kjJHaZMQTz-grRB-=b-=ghbe1qOQCQEMopcXEfw@mail.gmail.com>

On Fri, Oct 9, 2015 at 4:39 PM, William Burns <mudokonman at gmail.com> wrote:
>
>
> On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>> I'm not sure about including removals/invalidations/expiration,
>
>
> Invalidations to me don't quite fit, since it should be passivated in that
> case.

Passivations have a different listener, I didn't include
@CacheEntryPassivated here :)

Perhaps invalidation doesn't fit, because it's used to remove stale
entries either after a rebalance, or after a write (for L1 entries, or
in invalidation mode).

But then I would say expiration also doesn't fit, because the all the
others are direct actions by the user, and expiration happens in the
background.

>
>>
>> because there would be no way to say "I want to be notified on
>> creation and modification, but no removals". On the other hand, adding
>
>
> We could always add a parameter to the new annotation to say if you don't
> care about removals maybe?

Yes, that should work.

>
>>
>> 3 more methods delegating to the same implementation, while not
>> pretty, does allow you to listen to all changes.
>
>
> Do we need 3 methods?  Yes I think it would be nice for people.

I'm assuming the listener methods are checked to receive the right
event types. If we allow supertypes (and make CacheEntryWrittenEvent a
supertype of the others) it could be just 1 method with 4 annotations.

>
>>
>>
>> Or are you thinking that the 3 additional listeners would add
>> significant overhead when clustered?
>
>
> I was thinking it would be 1 listener.  CacheNotifierImpl could raise the
> new event in addition to the existing ones.

Right, if we include the removals in this annotation there would be
just one listener. But would it be faster than having 4 listeners, one
for create/update, and one each for remove/invalidation/expiration?

Cheers
Dan

From ttarrant at redhat.com  Mon Oct 12 11:02:38 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 12 Oct 2015 17:02:38 +0200
Subject: [infinispan-dev] Weekly IRC meeting minutes 2015-10-12
Message-ID: <561BCB8E.8020605@redhat.com>

Hi all,

get them from

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2015/infinispan.2015-10-12-14.00.log.html

Cheers

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

From dan.berindei at gmail.com  Wed Oct 14 10:43:40 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Wed, 14 Oct 2015 17:43:40 +0300
Subject: [infinispan-dev] Cache entry creation and modification events
In-Reply-To: <CA+nfvwSUzU6kjJHaZMQTz-grRB-=b-=ghbe1qOQCQEMopcXEfw@mail.gmail.com>
References: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
	<5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>
	<CA+YCuUNmsUe7FPFgWqa1TBYcoDHh_-c_c556rWO2PYZhM-47eg@mail.gmail.com>
	<CA+nfvwSyTZe4aAWhDnXwQ_t0n6LePoWmtgV3LrJ9PtJvhPUthg@mail.gmail.com>
	<CA+YCuUNqNvTkrF6UB32BvViQG9o_-zpZ1z4EdEtOt1B3WMj-JQ@mail.gmail.com>
	<CA+nfvwSUzU6kjJHaZMQTz-grRB-=b-=ghbe1qOQCQEMopcXEfw@mail.gmail.com>
Message-ID: <CA+nfvwQHwF89-54hvqmFz0f2Qqyu+guCqtuErTm1nOtdhTXk9w@mail.gmail.com>

There is one more thing to consider: the interface for acting on the
previous value of an event is very clunky even today. It basically
requires a thread-local to keep track of the previous value from the
pre=true invocation to the pre=false invocation, and even that won't
work once the reactive interceptor stack lands (so that pre and post
events are triggered on different threads).

So I'm starting to think we should go with option 1 for now, and start
a bigger redesign of the cache notifications for 9.0:
* Remove the pre=true events
* Add explicit event properties for the previous value/metadata

Without backwards compatibility requirements, we could even add a
skipPreviousValue parameter to all listener annotations -- except for
@CacheEntryCreated, I guess -- making the new listener type
superfluous.

Cheers
Dan


On Mon, Oct 12, 2015 at 11:02 AM, Dan Berindei <dan.berindei at gmail.com> wrote:
> On Fri, Oct 9, 2015 at 4:39 PM, William Burns <mudokonman at gmail.com> wrote:
>>
>>
>> On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei at gmail.com> wrote:
>>>
>>> I'm not sure about including removals/invalidations/expiration,
>>
>>
>> Invalidations to me don't quite fit, since it should be passivated in that
>> case.
>
> Passivations have a different listener, I didn't include
> @CacheEntryPassivated here :)
>
> Perhaps invalidation doesn't fit, because it's used to remove stale
> entries either after a rebalance, or after a write (for L1 entries, or
> in invalidation mode).
>
> But then I would say expiration also doesn't fit, because the all the
> others are direct actions by the user, and expiration happens in the
> background.
>
>>
>>>
>>> because there would be no way to say "I want to be notified on
>>> creation and modification, but no removals". On the other hand, adding
>>
>>
>> We could always add a parameter to the new annotation to say if you don't
>> care about removals maybe?
>
> Yes, that should work.
>
>>
>>>
>>> 3 more methods delegating to the same implementation, while not
>>> pretty, does allow you to listen to all changes.
>>
>>
>> Do we need 3 methods?  Yes I think it would be nice for people.
>
> I'm assuming the listener methods are checked to receive the right
> event types. If we allow supertypes (and make CacheEntryWrittenEvent a
> supertype of the others) it could be just 1 method with 4 annotations.
>
>>
>>>
>>>
>>> Or are you thinking that the 3 additional listeners would add
>>> significant overhead when clustered?
>>
>>
>> I was thinking it would be 1 listener.  CacheNotifierImpl could raise the
>> new event in addition to the existing ones.
>
> Right, if we include the removals in this annotation there would be
> just one listener. But would it be faster than having 4 listeners, one
> for create/update, and one each for remove/invalidation/expiration?
>
> Cheers
> Dan

From galder at redhat.com  Mon Oct 19 10:27:13 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 19 Oct 2015 16:27:13 +0200
Subject: [infinispan-dev] Weekly team meeting
Message-ID: <F419FFC4-F8C7-435F-BEF9-3CCF6F300D60@redhat.com>

Hi all,

Here are this week's team meeting minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2015/infinispan.2015-10-19-14.01.html

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat



From galder at redhat.com  Mon Oct 19 10:34:22 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 19 Oct 2015 16:34:22 +0200
Subject: [infinispan-dev] Cache entry creation and modification events
In-Reply-To: <CA+nfvwQHwF89-54hvqmFz0f2Qqyu+guCqtuErTm1nOtdhTXk9w@mail.gmail.com>
References: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
	<5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>
	<CA+YCuUNmsUe7FPFgWqa1TBYcoDHh_-c_c556rWO2PYZhM-47eg@mail.gmail.com>
	<CA+nfvwSyTZe4aAWhDnXwQ_t0n6LePoWmtgV3LrJ9PtJvhPUthg@mail.gmail.com>
	<CA+YCuUNqNvTkrF6UB32BvViQG9o_-zpZ1z4EdEtOt1B3WMj-JQ@mail.gmail.com>
	<CA+nfvwSUzU6kjJHaZMQTz-grRB-=b-=ghbe1qOQCQEMopcXEfw@mail.gmail.com>
	<CA+nfvwQHwF89-54hvqmFz0f2Qqyu+guCqtuErTm1nOtdhTXk9w@mail.gmail.com>
Message-ID: <BADBECE5-D96F-4F46-8AC4-4126E64B9151@redhat.com>



--
Galder Zamarre?o
Infinispan, Red Hat

> On 14 Oct 2015, at 16:43, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
> There is one more thing to consider: the interface for acting on the
> previous value of an event is very clunky even today. It basically
> requires a thread-local to keep track of the previous value from the
> pre=true invocation to the pre=false invocation, and even that won't
> work once the reactive interceptor stack lands (so that pre and post
> events are triggered on different threads).
> 
> So I'm starting to think we should go with option 1 for now, and start
> a bigger redesign of the cache notifications for 9.0:
> * Remove the pre=true events
> * Add explicit event properties for the previous value/metadata

Why redesign cache notifications? As I mentioned in a previous reply, I see Cache and cache notifications being phased out in favour of: JCache (and its events), ConcurrentMap and Functional Map (and its events) :|. 

So, no need to redesign Cache notifications IMO :|

> 
> Without backwards compatibility requirements, we could even add a
> skipPreviousValue parameter to all listener annotations -- except for
> @CacheEntryCreated, I guess -- making the new listener type
> superfluous.
> 
> Cheers
> Dan
> 
> 
> On Mon, Oct 12, 2015 at 11:02 AM, Dan Berindei <dan.berindei at gmail.com> wrote:
>> On Fri, Oct 9, 2015 at 4:39 PM, William Burns <mudokonman at gmail.com> wrote:
>>> 
>>> 
>>> On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei at gmail.com> wrote:
>>>> 
>>>> I'm not sure about including removals/invalidations/expiration,
>>> 
>>> 
>>> Invalidations to me don't quite fit, since it should be passivated in that
>>> case.
>> 
>> Passivations have a different listener, I didn't include
>> @CacheEntryPassivated here :)
>> 
>> Perhaps invalidation doesn't fit, because it's used to remove stale
>> entries either after a rebalance, or after a write (for L1 entries, or
>> in invalidation mode).
>> 
>> But then I would say expiration also doesn't fit, because the all the
>> others are direct actions by the user, and expiration happens in the
>> background.
>> 
>>> 
>>>> 
>>>> because there would be no way to say "I want to be notified on
>>>> creation and modification, but no removals". On the other hand, adding
>>> 
>>> 
>>> We could always add a parameter to the new annotation to say if you don't
>>> care about removals maybe?
>> 
>> Yes, that should work.
>> 
>>> 
>>>> 
>>>> 3 more methods delegating to the same implementation, while not
>>>> pretty, does allow you to listen to all changes.
>>> 
>>> 
>>> Do we need 3 methods?  Yes I think it would be nice for people.
>> 
>> I'm assuming the listener methods are checked to receive the right
>> event types. If we allow supertypes (and make CacheEntryWrittenEvent a
>> supertype of the others) it could be just 1 method with 4 annotations.
>> 
>>> 
>>>> 
>>>> 
>>>> Or are you thinking that the 3 additional listeners would add
>>>> significant overhead when clustered?
>>> 
>>> 
>>> I was thinking it would be 1 listener.  CacheNotifierImpl could raise the
>>> new event in addition to the existing ones.
>> 
>> Right, if we include the removals in this annotation there would be
>> just one listener. But would it be faster than having 4 listeners, one
>> for create/update, and one each for remove/invalidation/expiration?
>> 
>> Cheers
>> Dan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From vblagoje at redhat.com  Mon Oct 19 12:48:47 2015
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Mon, 19 Oct 2015 12:48:47 -0400
Subject: [infinispan-dev] Infinispan 8.1.0.Alpha2 is out
Message-ID: <56251EEF.2080404@redhat.com>

Dear all,

The second Alpha release of Infinispan 8.1 is now widely available. We 
have included the latest preview of the new admin console currently 
under heavy development. Using new admin console web application 
Infinispan server admins can now add new caches to a running domain 
server as well as boot new server instances. We have prepared mockups of 
the future admin console web app as a GitHub project. One can directly 
view mockups of future admin pages using rawgit service. The starting 
point for the admin console mockups is at 
https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-containers.html 
We would greatly appreciate your feedback regarding admin console web 
application. Let's shape it together!

For all other improvements including XSite HotRod failover, as well as 
bug fixes read the complete release notes. 8.1 Final is still on track 
for the end of November. If you are new to Infinispan learn how to use 
it, and help us continually improve it.

On the behalf of entire Infinispan team,
Vladimir

From dan.berindei at gmail.com  Tue Oct 20 09:05:12 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Tue, 20 Oct 2015 16:05:12 +0300
Subject: [infinispan-dev] Cache entry creation and modification events
In-Reply-To: <BADBECE5-D96F-4F46-8AC4-4126E64B9151@redhat.com>
References: <CA+nfvwS1MPKrFP9jLNTOJ_aqKgu8PbRjhcJr22Ra4B1qaw177w@mail.gmail.com>
	<5B578F7D-2A56-4110-A433-646A436873E5@redhat.com>
	<CA+YCuUNmsUe7FPFgWqa1TBYcoDHh_-c_c556rWO2PYZhM-47eg@mail.gmail.com>
	<CA+nfvwSyTZe4aAWhDnXwQ_t0n6LePoWmtgV3LrJ9PtJvhPUthg@mail.gmail.com>
	<CA+YCuUNqNvTkrF6UB32BvViQG9o_-zpZ1z4EdEtOt1B3WMj-JQ@mail.gmail.com>
	<CA+nfvwSUzU6kjJHaZMQTz-grRB-=b-=ghbe1qOQCQEMopcXEfw@mail.gmail.com>
	<CA+nfvwQHwF89-54hvqmFz0f2Qqyu+guCqtuErTm1nOtdhTXk9w@mail.gmail.com>
	<BADBECE5-D96F-4F46-8AC4-4126E64B9151@redhat.com>
Message-ID: <CA+nfvwT6FQRidqKFaR374Q9fQc2A3wwQ+uo3xuveR0C10bS3Ag@mail.gmail.com>

On Mon, Oct 19, 2015 at 5:34 PM, Galder Zamarre?o <galder at redhat.com> wrote:
>
>
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>> On 14 Oct 2015, at 16:43, Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>> There is one more thing to consider: the interface for acting on the
>> previous value of an event is very clunky even today. It basically
>> requires a thread-local to keep track of the previous value from the
>> pre=true invocation to the pre=false invocation, and even that won't
>> work once the reactive interceptor stack lands (so that pre and post
>> events are triggered on different threads).
>>
>> So I'm starting to think we should go with option 1 for now, and start
>> a bigger redesign of the cache notifications for 9.0:
>> * Remove the pre=true events
>> * Add explicit event properties for the previous value/metadata
>
> Why redesign cache notifications? As I mentioned in a previous reply, I see Cache and cache notifications being phased out in favour of: JCache (and its events), ConcurrentMap and Functional Map (and its events) :|.

How is the ConcurrentMap API different from the Cache API?

>
> So, no need to redesign Cache notifications IMO :|

I was assuming JCache listeners are implemented on top of the Cache
listeners, so they would need fixes in the Cache listeners to work
properly.

We could implement the JCache listeners directly in 9.0 and remove the
Cache listeners, I guess. But looking at the JCache API it looks like
their listeners need the previous value for all writes, unlike the
FunctionalMap listeners, so I think there will still be a need for a
lower-level implementation.

>
>>
>> Without backwards compatibility requirements, we could even add a
>> skipPreviousValue parameter to all listener annotations -- except for
>> @CacheEntryCreated, I guess -- making the new listener type
>> superfluous.
>>
>> Cheers
>> Dan
>>
>>
>> On Mon, Oct 12, 2015 at 11:02 AM, Dan Berindei <dan.berindei at gmail.com> wrote:
>>> On Fri, Oct 9, 2015 at 4:39 PM, William Burns <mudokonman at gmail.com> wrote:
>>>>
>>>>
>>>> On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei at gmail.com> wrote:
>>>>>
>>>>> I'm not sure about including removals/invalidations/expiration,
>>>>
>>>>
>>>> Invalidations to me don't quite fit, since it should be passivated in that
>>>> case.
>>>
>>> Passivations have a different listener, I didn't include
>>> @CacheEntryPassivated here :)
>>>
>>> Perhaps invalidation doesn't fit, because it's used to remove stale
>>> entries either after a rebalance, or after a write (for L1 entries, or
>>> in invalidation mode).
>>>
>>> But then I would say expiration also doesn't fit, because the all the
>>> others are direct actions by the user, and expiration happens in the
>>> background.
>>>
>>>>
>>>>>
>>>>> because there would be no way to say "I want to be notified on
>>>>> creation and modification, but no removals". On the other hand, adding
>>>>
>>>>
>>>> We could always add a parameter to the new annotation to say if you don't
>>>> care about removals maybe?
>>>
>>> Yes, that should work.
>>>
>>>>
>>>>>
>>>>> 3 more methods delegating to the same implementation, while not
>>>>> pretty, does allow you to listen to all changes.
>>>>
>>>>
>>>> Do we need 3 methods?  Yes I think it would be nice for people.
>>>
>>> I'm assuming the listener methods are checked to receive the right
>>> event types. If we allow supertypes (and make CacheEntryWrittenEvent a
>>> supertype of the others) it could be just 1 method with 4 annotations.
>>>
>>>>
>>>>>
>>>>>
>>>>> Or are you thinking that the 3 additional listeners would add
>>>>> significant overhead when clustered?
>>>>
>>>>
>>>> I was thinking it would be 1 listener.  CacheNotifierImpl could raise the
>>>> new event in addition to the existing ones.
>>>
>>> Right, if we include the removals in this annotation there would be
>>> just one listener. But would it be faster than having 4 listeners, one
>>> for create/update, and one each for remove/invalidation/expiration?
>>>
>>> Cheers
>>> Dan
>> _______________________________________________
>> 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 slaskawi at redhat.com  Wed Oct 21 03:51:32 2015
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 21 Oct 2015 09:51:32 +0200
Subject: [infinispan-dev] How about dropping Spring 3 support?
Message-ID: <CAA9R9O6DJbOByfNF4-SozHDbBP-O_VMrL5cTszqgzMO2t4BcKw@mail.gmail.com>

Hey!

I'm working on Spring and CDI package split (remote vs embedded) and I
would like to ask you about supporting Spring versions...

Currently we support Spring 3 [1] and Spring 4 [2]. Spring 4 was release a
while ago (Dec 12 2013 [3]) and as far as I know it's been widely adopted
in production.

So the main question - how about dropping support for Spring 3 and removing
this module from ISPN distribution?

Thanks
Sebastian

[1] https://github.com/infinispan/infinispan/tree/master/spring/spring
[2] https://github.com/infinispan/infinispan/tree/master/spring/spring4
[3]
https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20151021/477b7c54/attachment.html 

From gustavo at infinispan.org  Wed Oct 21 04:04:09 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Wed, 21 Oct 2015 09:04:09 +0100
Subject: [infinispan-dev] How about dropping Spring 3 support?
In-Reply-To: <CAA9R9O6DJbOByfNF4-SozHDbBP-O_VMrL5cTszqgzMO2t4BcKw@mail.gmail.com>
References: <CAA9R9O6DJbOByfNF4-SozHDbBP-O_VMrL5cTszqgzMO2t4BcKw@mail.gmail.com>
Message-ID: <2F524352-9B4C-4A38-A1A4-92006EF6913C@infinispan.org>

+1, but IMO it should be deprecated first, and removed in the next major version.

Gustavo 

> On 21 Oct 2015, at 08:51, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
> 
> Hey!
> 
> I'm working on Spring and CDI package split (remote vs embedded) and I would like to ask you about supporting Spring versions...
> 
> Currently we support Spring 3 [1] and Spring 4 [2]. Spring 4 was release a while ago (Dec 12 2013 [3]) and as far as I know it's been widely adopted in production. 
> 
> So the main question - how about dropping support for Spring 3 and removing this module from ISPN distribution?
> 
> Thanks
> Sebastian
> 
> [1] https://github.com/infinispan/infinispan/tree/master/spring/spring <https://github.com/infinispan/infinispan/tree/master/spring/spring>
> [2] https://github.com/infinispan/infinispan/tree/master/spring/spring4 <https://github.com/infinispan/infinispan/tree/master/spring/spring4>
> [3] https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release <https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release>_______________________________________________
> 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/20151021/195aa932/attachment-0001.html 

From dan.berindei at gmail.com  Wed Oct 21 06:35:10 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Wed, 21 Oct 2015 13:35:10 +0300
Subject: [infinispan-dev] How about dropping Spring 3 support?
In-Reply-To: <2F524352-9B4C-4A38-A1A4-92006EF6913C@infinispan.org>
References: <CAA9R9O6DJbOByfNF4-SozHDbBP-O_VMrL5cTszqgzMO2t4BcKw@mail.gmail.com>
	<2F524352-9B4C-4A38-A1A4-92006EF6913C@infinispan.org>
Message-ID: <CA+nfvwROtUCVpVN7TBJ0km2GgKn4Qg9sNFqkby03Q+iHYw3mvg@mail.gmail.com>

+1 to deprecate Spring 3 support in 8.x.

Dan


On Wed, Oct 21, 2015 at 11:04 AM, Gustavo Fernandes
<gustavo at infinispan.org> wrote:
> +1, but IMO it should be deprecated first, and removed in the next major
> version.
>
> Gustavo
>
> On 21 Oct 2015, at 08:51, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
>
> Hey!
>
> I'm working on Spring and CDI package split (remote vs embedded) and I would
> like to ask you about supporting Spring versions...
>
> Currently we support Spring 3 [1] and Spring 4 [2]. Spring 4 was release a
> while ago (Dec 12 2013 [3]) and as far as I know it's been widely adopted in
> production.
>
> So the main question - how about dropping support for Spring 3 and removing
> this module from ISPN distribution?
>
> Thanks
> Sebastian
>
> [1] https://github.com/infinispan/infinispan/tree/master/spring/spring
> [2] https://github.com/infinispan/infinispan/tree/master/spring/spring4
> [3]
> https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release
> _______________________________________________
> 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 ttarrant at redhat.com  Wed Oct 21 12:01:35 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 21 Oct 2015 18:01:35 +0200
Subject: [infinispan-dev] How about dropping Spring 3 support?
In-Reply-To: <CAA9R9O6DJbOByfNF4-SozHDbBP-O_VMrL5cTszqgzMO2t4BcKw@mail.gmail.com>
References: <CAA9R9O6DJbOByfNF4-SozHDbBP-O_VMrL5cTszqgzMO2t4BcKw@mail.gmail.com>
Message-ID: <5627B6DF.9090309@redhat.com>

As others have said. Let's kill it gracefully.

Tristan

On 21/10/2015 09:51, Sebastian Laskawiec wrote:
> Hey!
>
> I'm working on Spring and CDI package split (remote vs embedded) and I
> would like to ask you about supporting Spring versions...
>
> Currently we support Spring 3 [1] and Spring 4 [2]. Spring 4 was release
> a while ago (Dec 12 2013 [3]) and as far as I know it's been widely
> adopted in production.
>
> So the main question - how about dropping support for Spring 3 and
> removing this module from ISPN distribution?
>
> Thanks
> Sebastian
>
> [1] https://github.com/infinispan/infinispan/tree/master/spring/spring
> [2] https://github.com/infinispan/infinispan/tree/master/spring/spring4
> [3]
> https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release
>
>
> _______________________________________________
> 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 slaskawi at redhat.com  Thu Oct 22 01:54:08 2015
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 22 Oct 2015 07:54:08 +0200
Subject: [infinispan-dev] How about dropping Spring 3 support?
In-Reply-To: <5627B6DF.9090309@redhat.com>
References: <CAA9R9O6DJbOByfNF4-SozHDbBP-O_VMrL5cTszqgzMO2t4BcKw@mail.gmail.com>
	<5627B6DF.9090309@redhat.com>
Message-ID: <CAA9R9O4vtY8RMaaoCLyFYK2HjU=xQRuHJ2XuKtDV7KsEnf_ZGQ@mail.gmail.com>

Sounds good to me. Shall I add some note to READ.ME file or something
similar?

On Wed, Oct 21, 2015 at 6:01 PM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> As others have said. Let's kill it gracefully.
>
> Tristan
>
> On 21/10/2015 09:51, Sebastian Laskawiec wrote:
> > Hey!
> >
> > I'm working on Spring and CDI package split (remote vs embedded) and I
> > would like to ask you about supporting Spring versions...
> >
> > Currently we support Spring 3 [1] and Spring 4 [2]. Spring 4 was release
> > a while ago (Dec 12 2013 [3]) and as far as I know it's been widely
> > adopted in production.
> >
> > So the main question - how about dropping support for Spring 3 and
> > removing this module from ISPN distribution?
> >
> > Thanks
> > Sebastian
> >
> > [1] https://github.com/infinispan/infinispan/tree/master/spring/spring
> > [2] https://github.com/infinispan/infinispan/tree/master/spring/spring4
> > [3]
> >
> https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release
> >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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/20151022/4e74f6e5/attachment.html 

From ttarrant at redhat.com  Thu Oct 22 03:03:32 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 22 Oct 2015 09:03:32 +0200
Subject: [infinispan-dev] How about dropping Spring 3 support?
In-Reply-To: <CAA9R9O4vtY8RMaaoCLyFYK2HjU=xQRuHJ2XuKtDV7KsEnf_ZGQ@mail.gmail.com>
References: <CAA9R9O6DJbOByfNF4-SozHDbBP-O_VMrL5cTszqgzMO2t4BcKw@mail.gmail.com>
	<5627B6DF.9090309@redhat.com>
	<CAA9R9O4vtY8RMaaoCLyFYK2HjU=xQRuHJ2XuKtDV7KsEnf_ZGQ@mail.gmail.com>
Message-ID: <56288A44.6020908@redhat.com>

We have a section in the documentation about these things:

http://infinispan.org/docs/8.1.x/upgrading/upgrading.html

Tristan

On 22/10/2015 07:54, Sebastian Laskawiec wrote:
> Sounds good to me. Shall I add some note to READ.ME <http://READ.ME>
> file or something similar?
>
> On Wed, Oct 21, 2015 at 6:01 PM, Tristan Tarrant <ttarrant at redhat.com
> <mailto:ttarrant at redhat.com>> wrote:
>
>     As others have said. Let's kill it gracefully.
>
>     Tristan
>
>     On 21/10/2015 09:51, Sebastian Laskawiec wrote:
>      > Hey!
>      >
>      > I'm working on Spring and CDI package split (remote vs embedded)
>     and I
>      > would like to ask you about supporting Spring versions...
>      >
>      > Currently we support Spring 3 [1] and Spring 4 [2]. Spring 4 was
>     release
>      > a while ago (Dec 12 2013 [3]) and as far as I know it's been widely
>      > adopted in production.
>      >
>      > So the main question - how about dropping support for Spring 3 and
>      > removing this module from ISPN distribution?
>      >
>      > Thanks
>      > Sebastian
>      >
>      > [1]
>     https://github.com/infinispan/infinispan/tree/master/spring/spring
>      > [2]
>     https://github.com/infinispan/infinispan/tree/master/spring/spring4
>      > [3]
>      >
>     https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release
>      >
>      >
>     > _______________________________________________
>     > 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
>     >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     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
>
>
>
>
> _______________________________________________
> 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  Mon Oct 26 11:31:21 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 26 Oct 2015 16:31:21 +0100
Subject: [infinispan-dev] Weekly IRC meeting logs 2015-10-26
Message-ID: <562E4749.5080106@redhat.com>

Hi all,

the weekly meeting logs are available at:

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2015/infinispan.2015-10-26-15.00.log.html

Cheers

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

From ttarrant at redhat.com  Fri Oct 30 05:08:42 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 30 Oct 2015 10:08:42 +0100
Subject: [infinispan-dev] Static analysis (partial)
Message-ID: <5633339A.7070504@redhat.com>

During the review of [1] both Pedro and Will asked about whether a field 
could be null or not and I really wished I could use some kind of 
@NotNull annotation to clarify that. We already have findbugs included 
in our maven reports so what do you all think if we adopt those 
annotations just like we already do for the jcip ones ?

Tristan


[1] https://github.com/infinispan/infinispan/pull/3726
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From slaskawi at redhat.com  Fri Oct 30 05:53:43 2015
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Fri, 30 Oct 2015 10:53:43 +0100
Subject: [infinispan-dev] Static analysis (partial)
In-Reply-To: <5633339A.7070504@redhat.com>
References: <5633339A.7070504@redhat.com>
Message-ID: <CAA9R9O4fSp-7A7FW7ZTJcXaC4+oF_+XqRPXjfedeCDeepc1Yzg@mail.gmail.com>

+1 from me.

But since we are JDK8 based, how about using Optional for "optional"
parameters and "nothing" for required ones?

On Fri, Oct 30, 2015 at 10:08 AM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> During the review of [1] both Pedro and Will asked about whether a field
> could be null or not and I really wished I could use some kind of
> @NotNull annotation to clarify that. We already have findbugs included
> in our maven reports so what do you all think if we adopt those
> annotations just like we already do for the jcip ones ?
>
> Tristan
>
>
> [1] https://github.com/infinispan/infinispan/pull/3726
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20151030/6bdb215b/attachment.html 

From dan.berindei at gmail.com  Fri Oct 30 05:53:39 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Fri, 30 Oct 2015 11:53:39 +0200
Subject: [infinispan-dev] Static analysis (partial)
In-Reply-To: <5633339A.7070504@redhat.com>
References: <5633339A.7070504@redhat.com>
Message-ID: <CA+nfvwSbH9D3-1bGBbdmAh5+ca2vnoCYn8P5cbV5kXfa6OkQhg@mail.gmail.com>

You mean the JSR-305 annotations included in findbugs?

Yes, I think it would be a good idea.

Cheers
Dan


On Fri, Oct 30, 2015 at 11:08 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> During the review of [1] both Pedro and Will asked about whether a field
> could be null or not and I really wished I could use some kind of
> @NotNull annotation to clarify that. We already have findbugs included
> in our maven reports so what do you all think if we adopt those
> annotations just like we already do for the jcip ones ?
>
> Tristan
>
>
> [1] https://github.com/infinispan/infinispan/pull/3726
> --
> 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

From ttarrant at redhat.com  Fri Oct 30 06:15:58 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 30 Oct 2015 11:15:58 +0100
Subject: [infinispan-dev] Static analysis (partial)
In-Reply-To: <CA+nfvwSbH9D3-1bGBbdmAh5+ca2vnoCYn8P5cbV5kXfa6OkQhg@mail.gmail.com>
References: <5633339A.7070504@redhat.com>
	<CA+nfvwSbH9D3-1bGBbdmAh5+ca2vnoCYn8P5cbV5kXfa6OkQhg@mail.gmail.com>
Message-ID: <5633435E.8080200@redhat.com>

Yes,

although I'd probably not reference JSR-305 since it is dormant :)

Tristan

On 30/10/2015 10:53, Dan Berindei wrote:
> You mean the JSR-305 annotations included in findbugs?
>
> Yes, I think it would be a good idea.
>
> Cheers
> Dan
>
>
> On Fri, Oct 30, 2015 at 11:08 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>> During the review of [1] both Pedro and Will asked about whether a field
>> could be null or not and I really wished I could use some kind of
>> @NotNull annotation to clarify that. We already have findbugs included
>> in our maven reports so what do you all think if we adopt those
>> annotations just like we already do for the jcip ones ?
>>
>> Tristan
>>
>>
>> [1] https://github.com/infinispan/infinispan/pull/3726
>> --
>> 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
>

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

From ttarrant at redhat.com  Fri Oct 30 06:18:04 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 30 Oct 2015 11:18:04 +0100
Subject: [infinispan-dev] Static analysis (partial)
In-Reply-To: <CAA9R9O4fSp-7A7FW7ZTJcXaC4+oF_+XqRPXjfedeCDeepc1Yzg@mail.gmail.com>
References: <5633339A.7070504@redhat.com>
	<CAA9R9O4fSp-7A7FW7ZTJcXaC4+oF_+XqRPXjfedeCDeepc1Yzg@mail.gmail.com>
Message-ID: <563343DC.6020206@redhat.com>

Yes, I did think of that, and I like Optional a lot, but sometimes it is 
overkill.

Tristan

On 30/10/2015 10:53, Sebastian Laskawiec wrote:
> +1 from me.
>
> But since we are JDK8 based, how about using Optional for "optional"
> parameters and "nothing" for required ones?
>
> On Fri, Oct 30, 2015 at 10:08 AM, Tristan Tarrant <ttarrant at redhat.com
> <mailto:ttarrant at redhat.com>> wrote:
>
>     During the review of [1] both Pedro and Will asked about whether a field
>     could be null or not and I really wished I could use some kind of
>     @NotNull annotation to clarify that. We already have findbugs included
>     in our maven reports so what do you all think if we adopt those
>     annotations just like we already do for the jcip ones ?
>
>     Tristan
>
>
>     [1] https://github.com/infinispan/infinispan/pull/3726
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     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
>
>
>
>
> _______________________________________________
> 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 Oct 30 11:14:32 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 30 Oct 2015 15:14:32 +0000
Subject: [infinispan-dev] Early Access builds for JDK 8u72 b05 ,
 JDK 9 b88 and JDK 9 with Project Jigsaw build b86 are available on
 java.net
Message-ID: <56338958.7040904@oracle.com>


Hi Galder,

Early Access build for JDK 8u72 b05 <http://jdk8.java.net/download.html> 
is available on java.net, summary of changes are listed here. 
<http://download.java.net/jdk8u72/changes/jdk8u72-b05.html?q=download/jdk8u72/changes/jdk8u72-b05.html>

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

Early Access build for JDK 9 with Project Jigsaw b86 
<https://jdk9.java.net/jigsaw/> is available on java.net.

Changes for JDK 9 with Project Jigsaw b86 : -

  *   New options for the jdeps tool: -genmoduleinfo to generate draft
    module-info.java files, and -ct to do a compile-time analysis of
    references (i.e., follow all references leaving all classes in each
    referenced JAR file) rather than the default run-time analysis
    (which only follows references leaving referenced classes).
  *   jlink no longer does service binding by default.
  * Class::getPackage fixed to return null for array types, primitives,
    and void (bug reported by Chris Newland).
  * Improved messages in IllegalAccessExceptions thrown by core reflection.
  * java -verbose now works with -Xpatch .
  * The special token ALL-SYSTEM can be used with the -addmods option to
    add all system modules.
  * New methods Module::{addUses,canUse}, which are dynamic equivalents
    of service-use clauses in module declarations.

Rgds, Rory

-- 
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/20151030/853ba64a/attachment.html