From ttarrant at redhat.com  Mon May  4 10:46:04 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 04 May 2015 16:46:04 +0200
Subject: [infinispan-dev] Weekly IRC Meeting Logs 2015-05-04
Message-ID: <5547862C.10809@redhat.com>

Get them here:

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

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

From pedro at infinispan.org  Mon May  4 16:29:30 2015
From: pedro at infinispan.org (Pedro Ruivo)
Date: Mon, 04 May 2015 21:29:30 +0100
Subject: [infinispan-dev] Infinispan 7.2.0.Final is out!
Message-ID: <5547D6AA.4080407@infinispan.org>

Dear Infinispan community,

Version 7.2.0.Final is now available.

Release details on 
http://blog.infinispan.org/2015/05/infinispan-720final-is-out.html

Cheers,
Pedro

From ttarrant at redhat.com  Tue May  5 04:56:06 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Tue, 05 May 2015 10:56:06 +0200
Subject: [infinispan-dev] Infinispan 8 development begins
Message-ID: <554885A6.10503@redhat.com>

Hi all,

now that Infinispan 7.2.0.Final is out I want to outline the plans for 
the future.

Infinispan 8.x will bring many new features and internal refactoring and 
improvements. We will be moving to Java 8 to take advantage of the new 
language and JDK features such as lambdas, CompletableFuture, Optional, 
etc. We will finally move our core to a reactive design so to reduce 
resource usage and increase performance. We will be adding a monitoring 
and management console built into our server. We will be enhancing 
everything from querying, indexing, remote protocols, etc. We will be 
integrating with Apache Spark and OpenShift. For more details check out 
our roadmap @ http://infinispan.org/roadmap/

Since the scope of things we want to do during the 8.x cycle is quite 
large, it is altogether possible that 8.0 will be initially tagged as 
"experimental", giving us time to iron out any issues during the 8.1 
release cycle. However, we will do our best to make 8.0 usable from the 
get-go.
We will be maintaining the 7.2.x branch for quite a while.

Let's hack !

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

From sanne at infinispan.org  Wed May  6 19:02:36 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 7 May 2015 00:02:36 +0100
Subject: [infinispan-dev] ISPN-5443 blocking the WildFly upgrade
Message-ID: <CAFm4XO0QAeKM0i+cPR0kHfPkzeL-=4OnNjBb3aS-yDBCoMJrJg@mail.gmail.com>

If there was a quick solution for ISPN-5443, you might still make it
to get Infinispan 7.2.x in WildFly 9.

Time is very short, but Infinispan 7.2.0.CR1 wasn't affected ..

Thanks,
Sanne

From galder at redhat.com  Thu May  7 11:07:46 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 7 May 2015 17:07:46 +0200
Subject: [infinispan-dev] Remote Iterator design doc
In-Reply-To: <CAH8Ud1E_-B3PuiAP7LZ2cMicasFFeNjFndaM64xGbm-VcgnP6A@mail.gmail.com>
References: <CAH8Ud1E_-B3PuiAP7LZ2cMicasFFeNjFndaM64xGbm-VcgnP6A@mail.gmail.com>
Message-ID: <801561FF-305D-4155-91C3-BE10E66B2733@redhat.com>

Looks good, but had a question.

CloseableIterator is typed as CloseableIterator<E>, what's the type that the method would return? I guess that would be dependant on the converter? How are you going to represent that?

Cheers,

> On 28 Apr 2015, at 16:46, Gustavo Fernandes <gustavo at infinispan.org> wrote:
> 
> Hi all, just updated [1] 
> 
> Comments and feedback appreciated!
> 
> [1] https://github.com/infinispan/infinispan/wiki/Remote-Iterator
> 
> Thanks,
> Gustavo
> 
> _______________________________________________
> 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 ttarrant at redhat.com  Fri May  8 03:53:41 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 08 May 2015 09:53:41 +0200
Subject: [infinispan-dev] 7.2.1.Final release
Message-ID: <554C6B85.4000105@redhat.com>

A couple of issues were found while testing 7.2.0.Final together with 
WildFly 9.0.0.CR1. We are releasing our first point release hoping that 
WildFly 9 will be able to use our latest and greatest.


You can see the list of fixed issues on our issue tracker [1]. Download 
[2] the release and check out the 7.2 release notes [3] if you haven't 
already


Tristan

[1] 
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310799&version=12326758
[2] http://infinispan.org/download/
[3] http://infinispan.org/release-notes/
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From ttarrant at redhat.com  Fri May  8 05:45:37 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 08 May 2015 11:45:37 +0200
Subject: [infinispan-dev] Infinispan git branched for 7.2.x
Message-ID: <554C85C1.8080409@redhat.com>

Just a heads up:

I have created a 7.2.x branch. Master is now open for 8.0.

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

From ttarrant at redhat.com  Fri May  8 05:47:00 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 08 May 2015 11:47:00 +0200
Subject: [infinispan-dev] Infinispan git branched for 7.2.x
In-Reply-To: <554C85C1.8080409@redhat.com>
References: <554C85C1.8080409@redhat.com>
Message-ID: <554C8614.3090305@redhat.com>

Oops, I forgot to add that once [1] is merged, master will be JDK 8+ 
only, so make sure your JDKs are nice and fresh :)

Tristan

[1] https://github.com/infinispan/infinispan/pull/3445

On 08/05/2015 11:45, Tristan Tarrant wrote:
> Just a heads up:
>
> I have created a 7.2.x branch. Master is now open for 8.0.
>
> Tristan

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

From mudokonman at gmail.com  Fri May  8 15:37:32 2015
From: mudokonman at gmail.com (William Burns)
Date: Fri, 08 May 2015 19:37:32 +0000
Subject: [infinispan-dev] Remote Iterator design doc
In-Reply-To: <801561FF-305D-4155-91C3-BE10E66B2733@redhat.com>
References: <CAH8Ud1E_-B3PuiAP7LZ2cMicasFFeNjFndaM64xGbm-VcgnP6A@mail.gmail.com>
	<801561FF-305D-4155-91C3-BE10E66B2733@redhat.com>
Message-ID: <CA+YCuUPE10xOOjkFd7RUy=x6BEti1fUU6HK-+e9r=O2paBDsgw@mail.gmail.com>

That is a good point, Galder.  Unfortunately the return type is lost since
we only pass a name for the filterconverter factory instead of the
converter which contains the type.  We would have to allow the code to
specify the type in the assigned variable it is returned to or ask for a
Class instance to be passed for inline type inference.

<E> CloseableIterator<E> retrieveEntries(...)

CloseableIterator<E> retrieveEntries(..., Class<E> returnType)

:(

 - Will

On Thu, May 7, 2015 at 11:07 AM Galder Zamarre?o <galder at redhat.com> wrote:

> Looks good, but had a question.
>
> CloseableIterator is typed as CloseableIterator<E>, what's the type that
> the method would return? I guess that would be dependant on the converter?
> How are you going to represent that?
>
> Cheers,
>
> > On 28 Apr 2015, at 16:46, Gustavo Fernandes <gustavo at infinispan.org>
> wrote:
> >
> > Hi all, just updated [1]
> >
> > Comments and feedback appreciated!
> >
> > [1] https://github.com/infinispan/infinispan/wiki/Remote-Iterator
> >
> > Thanks,
> > Gustavo
> >
> > _______________________________________________
> > 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/20150508/f255c897/attachment.html 

From sanne at infinispan.org  Fri May  8 16:19:53 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Fri, 8 May 2015 21:19:53 +0100
Subject: [infinispan-dev] Remote Iterator design doc
In-Reply-To: <CA+YCuUPE10xOOjkFd7RUy=x6BEti1fUU6HK-+e9r=O2paBDsgw@mail.gmail.com>
References: <CAH8Ud1E_-B3PuiAP7LZ2cMicasFFeNjFndaM64xGbm-VcgnP6A@mail.gmail.com>
	<801561FF-305D-4155-91C3-BE10E66B2733@redhat.com>
	<CA+YCuUPE10xOOjkFd7RUy=x6BEti1fUU6HK-+e9r=O2paBDsgw@mail.gmail.com>
Message-ID: <CAFm4XO1SQ-Jptd2N45gtaXKHO1XZsB76Z0TY=qrYYFgRvVBJEA@mail.gmail.com>

Passing a type isn't too unusual. But what happens if the returned
content is actually of another type?

I would have such a method to also imply a filter on the type, that's
also useful in practice: either it's just a safeguard for when it's a
mono-type cache, or if the user wants to store multiple types in the
Cache he will probably need a type filter anyway.

BTW the CloseableIterator is what it is because we created that in
Infinispan Query; it's nothing more than an Iterator (which is also
type) but which makes it very clear to the user that resources will
leak if it's not closed properly.
It's a nice idea to reuse the contract for consistency, if it works
out. And of course we can evolve the Query API as well if we get
better ideas now.

-- Sanne


On 8 May 2015 at 20:37, William Burns <mudokonman at gmail.com> wrote:
> That is a good point, Galder.  Unfortunately the return type is lost since
> we only pass a name for the filterconverter factory instead of the converter
> which contains the type.  We would have to allow the code to specify the
> type in the assigned variable it is returned to or ask for a Class instance
> to be passed for inline type inference.
>
> <E> CloseableIterator<E> retrieveEntries(...)
>
> CloseableIterator<E> retrieveEntries(..., Class<E> returnType)
>
> :(
>
>  - Will
>
>
> On Thu, May 7, 2015 at 11:07 AM Galder Zamarre?o <galder at redhat.com> wrote:
>>
>> Looks good, but had a question.
>>
>> CloseableIterator is typed as CloseableIterator<E>, what's the type that
>> the method would return? I guess that would be dependant on the converter?
>> How are you going to represent that?
>>
>> Cheers,
>>
>> > On 28 Apr 2015, at 16:46, Gustavo Fernandes <gustavo at infinispan.org>
>> > wrote:
>> >
>> > Hi all, just updated [1]
>> >
>> > Comments and feedback appreciated!
>> >
>> > [1] https://github.com/infinispan/infinispan/wiki/Remote-Iterator
>> >
>> > Thanks,
>> > Gustavo
>> >
>> > _______________________________________________
>> > 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
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From ttarrant at redhat.com  Mon May 11 10:49:17 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 11 May 2015 16:49:17 +0200
Subject: [infinispan-dev] Weekly IRC Meeting log 2015-05-11
Message-ID: <5550C16D.9080305@redhat.com>

Get them here

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

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

From ttarrant at redhat.com  Wed May 13 12:42:36 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 13 May 2015 18:42:36 +0200
Subject: [infinispan-dev] Configuration changes proposal for 8.0
Message-ID: <55537EFC.3090702@redhat.com>

Hi all,

this is a list of proposed changes for 8.x that affect configuration and 
default behaviour. We built this list last year, but never acted upon 
it, but now I believe it's time to do these changes. Please 
comment/add/remove as you think is appropriate.

- Make IGNORE_RETURN_VALUES the default
- Drop asymmetric marshalling [1]
- Remove/change some transaction options [2]
- ReplicationQueue - one should not be allowed to specify it as an instance
- ReplicationQueue - enabled should be implicit ? interval > 0 || 
queueSize > 0. Also flushing when queueSize has been reached should 
happen async.
- AsyncStoreConfiguration.shutdownTimeout - 
force-immediate=?false[default]? (destructive)
                    .flushLockTimeout - remove as it is no longer used
- BackupConfigurationBuilder - remove getters and implicitly set 
BackupFailurePolicy
- allow setting failurePolicy by class not by string
- Reconsider usefulness of ClusterLoader
- DataContainer.properties - to be removed
- ExpirationConfiguration.reaperEnabled should be removed and the 
interval value used instead
- HashConfiguration - remove deprecated elements
- L1Configuration to fail if the reaper frequency interval is less or 
equal than 0
- LockingConfigurationBuilder.useLockStriping - remove it & 
writeSkewCheck enabled by default and removed
- SingletonStore - pushStateWhenCoordinator implicit by pushStateTimeout 
-> flushTimeout
- StateTransfer.fetchInMemoryState -> renamed to enabled
- StoreAsBinary - remove ?enabled? and reply on storeKey/storeBinary + 
remove deprecation
- remove deprecations from TransactionConfiguration and remove 
use1PcForAutCommitTx
- VersioningConfiguration.enabled should be computed based on the scheme 
and removed
- Version - remove the version fields and populate them through a mvn script
- SerializationConfigurationBuilder - consider removing the version field
- ShutdownConfiguration - to be removed, confirm with an email
- TransportConfiguration.distributedSyncTimeout -> global RPC timeout
- strictPeerToPeer should go as it is deprecated


[1] https://issues.jboss.org/browse/ISPN-2939
[2] https://issues.jboss.org/browse/ISPN-3927
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From pedro at infinispan.org  Wed May 13 13:07:26 2015
From: pedro at infinispan.org (Pedro Ruivo)
Date: Wed, 13 May 2015 18:07:26 +0100
Subject: [infinispan-dev] Configuration changes proposal for 8.0
In-Reply-To: <55537EFC.3090702@redhat.com>
References: <55537EFC.3090702@redhat.com>
Message-ID: <555384CE.9030208@infinispan.org>

Hi,

comments inline

Pedro

On 05/13/2015 05:42 PM, Tristan Tarrant wrote:
> Hi all,
>
> this is a list of proposed changes for 8.x that affect configuration and
> default behaviour. We built this list last year, but never acted upon
> it, but now I believe it's time to do these changes. Please
> comment/add/remove as you think is appropriate.
>
> - Make IGNORE_RETURN_VALUES the default

hmmm, not sure about it. it only makes sense for put(k,v) and 
remove(k,v) since all other write operations are conditional (i.e. need 
the previous value and no optimization can be made)

> - Drop asymmetric marshalling [1]
> - Remove/change some transaction options [2]
> - ReplicationQueue - one should not be allowed to specify it as an instance
> - ReplicationQueue - enabled should be implicit ? interval > 0 ||
> queueSize > 0. Also flushing when queueSize has been reached should
> happen async.

Can we remove the ReplicationQueue? First, it does not have any benefit 
(JGroups already bundles the message and the Network can do it too) and 
second, it is not more efficient (when the message is delivered, we 
process the commands sequentially. So, if the first command blocks, the 
other commands are not processed until it finished). Third, it is 
complex if you have commands with multiple delivers orders (no order, 
FIFO, total)

> - AsyncStoreConfiguration.shutdownTimeout -
> force-immediate=?false[default]? (destructive)
>                      .flushLockTimeout - remove as it is no longer used
> - BackupConfigurationBuilder - remove getters and implicitly set
> BackupFailurePolicy
> - allow setting failurePolicy by class not by string
> - Reconsider usefulness of ClusterLoader

didn't get this one ^

> - DataContainer.properties - to be removed

so, we will not allow any custom implementation to be configured? or I 
miss something?

> - ExpirationConfiguration.reaperEnabled should be removed and the
> interval value used instead
> - HashConfiguration - remove deprecated elements
> - L1Configuration to fail if the reaper frequency interval is less or
> equal than 0
> - LockingConfigurationBuilder.useLockStriping - remove it &
> writeSkewCheck enabled by default and removed

write skew check should be moved to Transactions. It is the only place 
in which it makes sense

> - SingletonStore - pushStateWhenCoordinator implicit by pushStateTimeout
> -> flushTimeout
> - StateTransfer.fetchInMemoryState -> renamed to enabled
> - StoreAsBinary - remove ?enabled? and reply on storeKey/storeBinary +
> remove deprecation
> - remove deprecations from TransactionConfiguration and remove
> use1PcForAutCommitTx
> - VersioningConfiguration.enabled should be computed based on the scheme
> and removed
> - Version - remove the version fields and populate them through a mvn script
> - SerializationConfigurationBuilder - consider removing the version field
> - ShutdownConfiguration - to be removed, confirm with an email
> - TransportConfiguration.distributedSyncTimeout -> global RPC timeout
> - strictPeerToPeer should go as it is deprecated
>

another suggestion:

- Transaction, remove the transaction_protocol and add TOTAL as an 
option for locking_mode

*or*

- Transaction, remove the transaction_protocol
- Locking, add locking mode with LOCK and TOTAL_ORDER options (since 
I'll probably implement total order based non transactional caches)

>
> [1] https://issues.jboss.org/browse/ISPN-2939
> [2] https://issues.jboss.org/browse/ISPN-3927
>

From dan.berindei at gmail.com  Thu May 14 10:40:59 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Thu, 14 May 2015 17:40:59 +0300
Subject: [infinispan-dev] Configuration changes proposal for 8.0
In-Reply-To: <555384CE.9030208@infinispan.org>
References: <55537EFC.3090702@redhat.com> <555384CE.9030208@infinispan.org>
Message-ID: <CA+nfvwQTDyaJkQz78YBcv1AP6wwbJOa-XC-mDLM4sbUnXnmgbw@mail.gmail.com>

On Wed, May 13, 2015 at 8:07 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
> Hi,
>
> comments inline
>
> Pedro
>
> On 05/13/2015 05:42 PM, Tristan Tarrant wrote:
>> Hi all,
>>
>> this is a list of proposed changes for 8.x that affect configuration and
>> default behaviour. We built this list last year, but never acted upon
>> it, but now I believe it's time to do these changes. Please
>> comment/add/remove as you think is appropriate.
>>
>> - Make IGNORE_RETURN_VALUES the default
>
> hmmm, not sure about it. it only makes sense for put(k,v) and
> remove(k,v) since all other write operations are conditional (i.e. need
> the previous value and no optimization can be made)

For putIfAbsent(k, v) it also helps if you don't have to return the
previous value, and I would expect most write operations to be put(k,
v) anyway.

On the other hand, why not adopt the JCache interface and stop implementing Map?

>
>> - Drop asymmetric marshalling [1]

+1, but it should be *asynchronous* marshalling.

>> - Remove/change some transaction options [2]
>> - ReplicationQueue - one should not be allowed to specify it as an instance
>> - ReplicationQueue - enabled should be implicit ? interval > 0 ||
>> queueSize > 0. Also flushing when queueSize has been reached should
>> happen async.
>
> Can we remove the ReplicationQueue? First, it does not have any benefit
> (JGroups already bundles the message and the Network can do it too) and
> second, it is not more efficient (when the message is delivered, we
> process the commands sequentially. So, if the first command blocks, the
> other commands are not processed until it finished). Third, it is
> complex if you have commands with multiple delivers orders (no order,
> FIFO, total)

+1, the replication queue has the same purpose as the bundler in
JGroups. And while the JGroups bundler has multiple options that keep
evolving, our replication queue still has the same algorithm it had in
4.0.

>
>> - AsyncStoreConfiguration.shutdownTimeout -
>> force-immediate=?false[default]? (destructive)
>>                      .flushLockTimeout - remove as it is no longer used
>> - BackupConfigurationBuilder - remove getters and implicitly set
>> BackupFailurePolicy
>> - allow setting failurePolicy by class not by string
>> - Reconsider usefulness of ClusterLoader
>
> didn't get this one ^

-1 from me to remove the ClusterLoader, unless we replace it with a
better integrated alternative for invalidation mode.

>
>> - DataContainer.properties - to be removed
>
> so, we will not allow any custom implementation to be configured? or I
> miss something?
>
>> - ExpirationConfiguration.reaperEnabled should be removed and the
>> interval value used instead
>> - HashConfiguration - remove deprecated elements

Here I would suggest also replacing the Hash with another interface:
https://issues.jboss.org/browse/ISPN-5465

>> - L1Configuration to fail if the reaper frequency interval is less or
>> equal than 0
>> - LockingConfigurationBuilder.useLockStriping - remove it &
>> writeSkewCheck enabled by default and removed
>

+1 to remove lock striping

> write skew check should be moved to Transactions. It is the only place
> in which it makes sense

+1 to enable writeSkewCheck by default
+1 to remove it from the locking configuration. But I think "write
skew disabled" should be another locking mode, perhaps called
LAST_WRITE_WINS.

>
>> - SingletonStore - pushStateWhenCoordinator implicit by pushStateTimeout
>> -> flushTimeout
>> - StateTransfer.fetchInMemoryState -> renamed to enabled

+1

>> - StoreAsBinary - remove ?enabled? and reply on storeKey/storeBinary +
>> remove deprecation
>> - remove deprecations from TransactionConfiguration and remove
>> use1PcForAutCommitTx

+1

>> - VersioningConfiguration.enabled should be computed based on the scheme
>> and removed

+1

>> - Version - remove the version fields and populate them through a mvn script
>> - SerializationConfigurationBuilder - consider removing the version field

+1 to remove it, the javadoc there suggests we support
interoperability between different Infinispan versions and that's
still too onerous for us at this point.

>> - ShutdownConfiguration - to be removed, confirm with an email
>> - TransportConfiguration.distributedSyncTimeout -> global RPC timeout

+1

>> - strictPeerToPeer should go as it is deprecated

+1

>>
>
> another suggestion:
>
> - Transaction, remove the transaction_protocol and add TOTAL as an
> option for locking_mode
>
> *or*
>
> - Transaction, remove the transaction_protocol
> - Locking, add locking mode with LOCK and TOTAL_ORDER options (since
> I'll probably implement total order based non transactional caches)

I don't feel like TOTAL belongs to the locking element. Since total
order is only relevant in clustered caches, how about making it an
alternative clustering mode?

<clustering mode="SYNC|ASYNC|TOTAL"/>


>
>>
>> [1] https://issues.jboss.org/browse/ISPN-2939
>> [2] https://issues.jboss.org/browse/ISPN-3927
>>


From slaskawi at redhat.com  Thu May 14 11:28:40 2015
From: slaskawi at redhat.com (=?UTF-8?B?U2ViYXN0aWFuIMWBYXNrYXdpZWM=?=)
Date: Thu, 14 May 2015 17:28:40 +0200
Subject: [infinispan-dev] Configuration changes proposal for 8.0
In-Reply-To: <55537EFC.3090702@redhat.com>
References: <55537EFC.3090702@redhat.com>
Message-ID: <5554BF28.1070507@redhat.com>



On 05/13/2015 06:42 PM, Tristan Tarrant wrote:
> - Version - remove the version fields and populate them through a mvn script
+1 and I think it would be great to have a full version and SHA1 in each 
jars manifest.

Thanks
Sebastian

From smarlow at redhat.com  Fri May 15 10:38:32 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 15 May 2015 10:38:32 -0400
Subject: [infinispan-dev] missing "int
 org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()" &
 NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1
Message-ID: <555604E8.9080302@redhat.com>

Applications that compile against Infinispan 6.x, will expect that 
org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() 
returns an int but when they run against Infinispan 7.x, they will not 
find this method (since maxEntries() returns a long).

Is this a known bug or issue on Infinispan 7.x?  Can you recommend a 
solution or workaround for applications that currently depend on 
maxEntries returning an int but aren't ready to recompile against 
Infinispan 7?

Also see the original discussion from last night on hibernate-dev ml [1][2].

Scott

[1] http://lists.jboss.org/pipermail/hibernate-dev/2015-May/012715.html
[2] http://lists.jboss.org/pipermail/hibernate-dev/2015-May/012725.html

From ttarrant at redhat.com  Fri May 15 11:00:08 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 15 May 2015 17:00:08 +0200
Subject: [infinispan-dev] missing "int
 org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()" &
 NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1
In-Reply-To: <555604E8.9080302@redhat.com>
References: <555604E8.9080302@redhat.com>
Message-ID: <555609F8.2020007@redhat.com>

On 15/05/2015 16:38, Scott Marlow wrote:
> Applications that compile against Infinispan 6.x, will expect that
> org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()
> returns an int but when they run against Infinispan 7.x, they will not
> find this method (since maxEntries() returns a long).
>
> Is this a known bug or issue on Infinispan 7.x?

Since this was changed in a minor release (7.2) it definitely is a bug. 
While we can provide overloaded setters, doing so for a getter is 
obviously not possible. We should probably release a 7.2.2 which 
restores "int maxEntries()" and adds a "long maxEntriesAsLong()".

However be aware that for 8.0 we want to remove the "int" variants 
altogether.

> Can you recommend a
> solution or workaround for applications that currently depend on
> maxEntries returning an int but aren't ready to recompile against
> Infinispan 7?

I believe the only "safe" solution is to use (yuck) reflection for now...

Tristan

>
> Also see the original discussion from last night on hibernate-dev ml [1][2].
>
> Scott
>
> [1] http://lists.jboss.org/pipermail/hibernate-dev/2015-May/012715.html
> [2] http://lists.jboss.org/pipermail/hibernate-dev/2015-May/012725.html
> _______________________________________________
> 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 smarlow at redhat.com  Fri May 15 11:50:12 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 15 May 2015 11:50:12 -0400
Subject: [infinispan-dev] missing "int
 org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()" &
 NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1
In-Reply-To: <555609F8.2020007@redhat.com>
References: <555604E8.9080302@redhat.com> <555609F8.2020007@redhat.com>
Message-ID: <555615B4.8090104@redhat.com>


On 05/15/2015 11:00 AM, Tristan Tarrant wrote:
> On 15/05/2015 16:38, Scott Marlow wrote:
>> Applications that compile against Infinispan 6.x, will expect that
>> org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()
>> returns an int but when they run against Infinispan 7.x, they will not
>> find this method (since maxEntries() returns a long).
>>
>> Is this a known bug or issue on Infinispan 7.x?
>
> Since this was changed in a minor release (7.2) it definitely is a bug.
> While we can provide overloaded setters, doing so for a getter is
> obviously not possible. We should probably release a 7.2.2 which
> restores "int maxEntries()" and adds a "long maxEntriesAsLong()".

Thanks Tristan, do you need a jira for this?

>
> However be aware that for 8.0 we want to remove the "int" variants
> altogether.

I heard that Infinispan 8.0 might get integrated into WildFly 10.  I 
think that WildFly 10 might be somewhat time boxed (check with Jason on 
exact details of that :).  As such, we might also Hibernate 5.0 also 
integrated into WildFly 10 (if that fits into the schedule).  If 
Hibernate ORM 5.0 doesn't get integrated in time for WildFly 10, then we 
would likely try to keep using a Hibernate 4.3.x release.

My next question is whether the hibernate-infinispan [1] will need 
changes for 8.0?  And whether that could be done in Hibernate 4.3.x + 
5.x, or if those changes need to be done in Hibernate 5.x (current 
Hibernate ORM master) only.  This question is probably best answered by 
Galder (expert on the hibernate-infinispan module) but input from others 
are welcome.  :-)

Thanks,
Scott

[1] 
https://github.com/hibernate/hibernate-orm/tree/master/hibernate-infinispan


From sanne at infinispan.org  Fri May 15 12:43:14 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Fri, 15 May 2015 17:43:14 +0100
Subject: [infinispan-dev] missing "int
 org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()" &
 NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1
In-Reply-To: <555615B4.8090104@redhat.com>
References: <555604E8.9080302@redhat.com> <555609F8.2020007@redhat.com>
	<555615B4.8090104@redhat.com>
Message-ID: <CAFm4XO1XObatf6WPLifEvXY+p=zP4sLoE_FfHUNoe8Z-FtLUhQ@mail.gmail.com>

On 15 May 2015 at 16:50, Scott Marlow <smarlow at redhat.com> wrote:
>
> On 05/15/2015 11:00 AM, Tristan Tarrant wrote:
>> On 15/05/2015 16:38, Scott Marlow wrote:
>>> Applications that compile against Infinispan 6.x, will expect that
>>> org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()
>>> returns an int but when they run against Infinispan 7.x, they will not
>>> find this method (since maxEntries() returns a long).
>>>
>>> Is this a known bug or issue on Infinispan 7.x?
>>
>> Since this was changed in a minor release (7.2) it definitely is a bug.
>> While we can provide overloaded setters, doing so for a getter is
>> obviously not possible. We should probably release a 7.2.2 which
>> restores "int maxEntries()" and adds a "long maxEntriesAsLong()".
>
> Thanks Tristan, do you need a jira for this?
>
>>
>> However be aware that for 8.0 we want to remove the "int" variants
>> altogether.
>
> I heard that Infinispan 8.0 might get integrated into WildFly 10.  I
> think that WildFly 10 might be somewhat time boxed (check with Jason on
> exact details of that :).  As such, we might also Hibernate 5.0 also
> integrated into WildFly 10 (if that fits into the schedule).  If
> Hibernate ORM 5.0 doesn't get integrated in time for WildFly 10, then we
> would likely try to keep using a Hibernate 4.3.x release.
>
> My next question is whether the hibernate-infinispan [1] will need
> changes for 8.0?  And whether that could be done in Hibernate 4.3.x +
> 5.x, or if those changes need to be done in Hibernate 5.x (current
> Hibernate ORM master) only.  This question is probably best answered by
> Galder (expert on the hibernate-infinispan module) but input from others
> are welcome.  :-)

Yes the hibernate-infinispan module will need maintenance as usual,
but don't bother to update Infinispan in Hibernate 4.3, as WildFly 10
has to have Hibernate 5.

We can focus on the hibernate-infinispan module in branch master only
(Hibernate 5), but also let's try to not realize update needs last
minute.

Thanks,
Sanne

>
> Thanks,
> Scott
>
> [1]
> https://github.com/hibernate/hibernate-orm/tree/master/hibernate-infinispan
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From smarlow at redhat.com  Fri May 15 13:16:50 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 15 May 2015 13:16:50 -0400
Subject: [infinispan-dev] missing "int
 org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()" &
 NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1
In-Reply-To: <CAFm4XO1XObatf6WPLifEvXY+p=zP4sLoE_FfHUNoe8Z-FtLUhQ@mail.gmail.com>
References: <555604E8.9080302@redhat.com>
	<555609F8.2020007@redhat.com>	<555615B4.8090104@redhat.com>
	<CAFm4XO1XObatf6WPLifEvXY+p=zP4sLoE_FfHUNoe8Z-FtLUhQ@mail.gmail.com>
Message-ID: <55562A02.3050802@redhat.com>



On 05/15/2015 12:43 PM, Sanne Grinovero wrote:
> Yes the hibernate-infinispan module will need maintenance as usual,
> but don't bother to update Infinispan in Hibernate 4.3, as WildFly 10
> has to have Hibernate 5.

This is a valid choice but also means that Infinispan 8 will not work 
with WildFly 10, if Hibernate 5 is not ready in time for the WildFly 10 
release.  I think that we all probably heard that WildFly 10 is supposed 
to be a short release.  Perhaps the involved project leads should 
discuss this (Infinispan/HibernateOrm/WildFly) and sync up on scheduling 
so there are no surprises/last minute integration efforts.

>
> We can focus on the hibernate-infinispan module in branch master only
> (Hibernate 5), but also let's try to not realize update needs last
> minute.

To me this is more of a personal preference on how the one person that 
knows how to do the integration (between Infinispan/Hibernate), does 
their work.  But, sure, lets "try".  Perhaps keeping a 
hibernate-infinispan branch up to date Infinispan changes, would be 
helpful.  Galder, I hope these suggestions are helpful and not as 
annoying as I suspect they may be. ;)

From sanne at infinispan.org  Fri May 15 14:54:20 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Fri, 15 May 2015 19:54:20 +0100
Subject: [infinispan-dev] missing "int
 org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()" &
 NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1
In-Reply-To: <55562A02.3050802@redhat.com>
References: <555604E8.9080302@redhat.com> <555609F8.2020007@redhat.com>
	<555615B4.8090104@redhat.com>
	<CAFm4XO1XObatf6WPLifEvXY+p=zP4sLoE_FfHUNoe8Z-FtLUhQ@mail.gmail.com>
	<55562A02.3050802@redhat.com>
Message-ID: <CAFm4XO2ks25QksPgtoMYgSZeH1u+QXav-4xEZv2f3dxtCJdaMQ@mail.gmail.com>

On 15 May 2015 at 18:16, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 05/15/2015 12:43 PM, Sanne Grinovero wrote:
>> Yes the hibernate-infinispan module will need maintenance as usual,
>> but don't bother to update Infinispan in Hibernate 4.3, as WildFly 10
>> has to have Hibernate 5.
>
> This is a valid choice but also means that Infinispan 8 will not work
> with WildFly 10, if Hibernate 5 is not ready in time for the WildFly 10
> release.  I think that we all probably heard that WildFly 10 is supposed
> to be a short release.  Perhaps the involved project leads should
> discuss this (Infinispan/HibernateOrm/WildFly) and sync up on scheduling
> so there are no surprises/last minute integration efforts.

Infinispan doesn't depend on a specific version of Hibernate, so while
I'm pretty sure that Infinispan 8 will be ready on time I don't see
why that would be a problem if - hypothetically - at last minute
WildFly 10 were to pick Infinispan 7 instead.

>> We can focus on the hibernate-infinispan module in branch master only
>> (Hibernate 5), but also let's try to not realize update needs last
>> minute.
>
> To me this is more of a personal preference on how the one person that
> knows how to do the integration (between Infinispan/Hibernate), does
> their work.  But, sure, lets "try".  Perhaps keeping a
> hibernate-infinispan branch up to date Infinispan changes, would be
> helpful.  Galder, I hope these suggestions are helpful and not as
> annoying as I suspect they may be. ;)

It might not be a good idea to update Hibernate to a version of
Infinispan which might not be included, until you're sure. I agree
it's nice to try keeping up - in secondary branches - to make sure one
is aware of what might be needed, and possibly raise issues in
advance. And anyone can start such an experiment.

For sure Galder is the most expert on the module, but with "let's try"
I really meant all of us. This has to be cross-team teamwork.
It's not an unilateral decision of the Hibernate team to pick which
version is being merged in WildFly, and so for Infinispan. WildFly
being the integration, it's up to WildFly to choose a compatible
combination, and that's not necessarily the latest of each.

So while project leads and components leads can give some advice,
ultimately it's up to who needs them to work together who should watch
out, possibly running integration tests and TCKs well in advance to
see integration issues coming. The earlier reported, the better for
all.
Also note that one project *might not want to* depend on the version
which WildFly plans to use.. really WildFly should be prepared to run
his own tests overriding the versions, and I wouldn't advice starting
such a job during CR1.

Thanks,
Sanne

From smarlow at redhat.com  Mon May 18 10:28:24 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 18 May 2015 10:28:24 -0400
Subject: [infinispan-dev] missing "int
 org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()" &
 NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1
In-Reply-To: <CAFm4XO2ks25QksPgtoMYgSZeH1u+QXav-4xEZv2f3dxtCJdaMQ@mail.gmail.com>
References: <555604E8.9080302@redhat.com>
	<555609F8.2020007@redhat.com>	<555615B4.8090104@redhat.com>	<CAFm4XO1XObatf6WPLifEvXY+p=zP4sLoE_FfHUNoe8Z-FtLUhQ@mail.gmail.com>	<55562A02.3050802@redhat.com>
	<CAFm4XO2ks25QksPgtoMYgSZeH1u+QXav-4xEZv2f3dxtCJdaMQ@mail.gmail.com>
Message-ID: <5559F708.5070106@redhat.com>



On 05/15/2015 02:54 PM, Sanne Grinovero wrote:
> On 15 May 2015 at 18:16, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>
>> On 05/15/2015 12:43 PM, Sanne Grinovero wrote:
>>> Yes the hibernate-infinispan module will need maintenance as usual,
>>> but don't bother to update Infinispan in Hibernate 4.3, as WildFly 10
>>> has to have Hibernate 5.
>>
>> This is a valid choice but also means that Infinispan 8 will not work
>> with WildFly 10, if Hibernate 5 is not ready in time for the WildFly 10
>> release.  I think that we all probably heard that WildFly 10 is supposed
>> to be a short release.  Perhaps the involved project leads should
>> discuss this (Infinispan/HibernateOrm/WildFly) and sync up on scheduling
>> so there are no surprises/last minute integration efforts.
>
> Infinispan doesn't depend on a specific version of Hibernate, so while
> I'm pretty sure that Infinispan 8 will be ready on time I don't see
> why that would be a problem if - hypothetically - at last minute
> WildFly 10 were to pick Infinispan 7 instead.
>
>>> We can focus on the hibernate-infinispan module in branch master only
>>> (Hibernate 5), but also let's try to not realize update needs last
>>> minute.
>>
>> To me this is more of a personal preference on how the one person that
>> knows how to do the integration (between Infinispan/Hibernate), does
>> their work.  But, sure, lets "try".  Perhaps keeping a
>> hibernate-infinispan branch up to date Infinispan changes, would be
>> helpful.  Galder, I hope these suggestions are helpful and not as
>> annoying as I suspect they may be. ;)
>
> It might not be a good idea to update Hibernate to a version of
> Infinispan which might not be included, until you're sure. I agree
> it's nice to try keeping up - in secondary branches - to make sure one
> is aware of what might be needed, and possibly raise issues in
> advance. And anyone can start such an experiment.
>
> For sure Galder is the most expert on the module, but with "let's try"
> I really meant all of us. This has to be cross-team teamwork.
> It's not an unilateral decision of the Hibernate team to pick which
> version is being merged in WildFly, and so for Infinispan. WildFly
> being the integration, it's up to WildFly to choose a compatible
> combination, and that's not necessarily the latest of each.
>
> So while project leads and components leads can give some advice,
> ultimately it's up to who needs them to work together who should watch
> out, possibly running integration tests and TCKs well in advance to
> see integration issues coming. The earlier reported, the better for
> all.
> Also note that one project *might not want to* depend on the version
> which WildFly plans to use.. really WildFly should be prepared to run
> his own tests overriding the versions, and I wouldn't advice starting
> such a job during CR1.

Probably would be better to understand why the hibernate-infinispan 
module is being broken by Infinispan upstream changes and whether a more 
pro-active approach could help.

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

From ttarrant at redhat.com  Mon May 18 10:47:40 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 18 May 2015 16:47:40 +0200
Subject: [infinispan-dev] Weekly IRC Meeting minutes 2015-05-18
Message-ID: <5559FB8C.8050804@redhat.com>

Hi all, since JBott was misbehaving, I'm pasting the meeting minutes here:

16:06:47 <ttarrant>	#startmeeting
16:07:06 <ttarrant>	#topic ttarrant
16:08:28 <ttarrant>	I have finally finished ISPN-4919
16:08:29 <jbossbot>	jira [ISPN-4919] Configuration templates [Open 
(Unresolved) Feature Request, Major, Tristan Tarrant] 
https://issues.jboss.org/browse/ISPN-4919
16:09:18 <ttarrant>	I had to give up on the multiple <caches > solution
16:11:49 <ttarrant>	I've also worked on 
https://github.com/infinispan/infinispan-cachestore-archetype/pull/1
16:11:50 <jbossbot>	git pull req [infinispan-cachestore-archetype] 
(open) tristantarrant Flesh out the archetypes with addtional 
documentation and tips 
https://github.com/infinispan/infinispan-cachestore-archetype/pull/1
16:11:55 <ttarrant>	please review that too
16:12:24 <ttarrant>	this week I intend to start work on rebasing to WF Core
16:13:40 <ttarrant>	so that means implementing the feature pack, 
dropping any dependencies on the clustering common packages, renaming 
the infinispan subsystem internal name to avoid conflict with WF, and 
porting the new fork-based jgroups subsystem from WF
16:14:27 <ttarrant>	I also intend to package the subsystems as part of 
our AS modules distribution
16:15:03 <ttarrant>	I also created the beer poll
16:15:27 <ttarrant>	there were quite a few suggestions, from which I 
extracted the top 6
16:15:34 <ttarrant>	get everyone to vote please
16:15:43 <ttarrant>	I want to release 8.0.0.Alpha1 this friday
16:15:51 <ttarrant>	as well as a 7.2.2.Final quite soon
16:16:00 <ttarrant>	that's it from me
16:16:08 <ttarrant>	#topic dberindei
16:16:34 <dberindei>	last week I finished ISPN-5460 and ISPN-5462
16:16:35 <jbossbot>	jira [ISPN-5460] Prepare commands sent before the 
target became a member should be rejected [Resolved (Done) Bug, 
Critical, Dan Berindei] https://issues.jboss.org/browse/ISPN-5460
16:16:35 <jbossbot>	jira [ISPN-5462] Transaction prepare is not 
replicated to new owners during state transfer [Resolved (Done) Bug, 
Critical, Dan Berindei] https://issues.jboss.org/browse/ISPN-5462
16:17:09 <dberindei>	then I wrote up some JIRAs for the reactive 
interceptor stack
16:17:22 <dberindei>	I started with ISPN-2154
16:17:23 <jbossbot>	jira [ISPN-2154] Use JGroups' anycast when sending 
messages to multiple target [Open (Unresolved) Task, Minor, Dan 
Berindei] https://issues.jboss.org/browse/ISPN-2154
16:17:54 <dberindei>	but then I got started on a bit of test suite cleanup
16:18:20 <dberindei>	and I issued PRs for ISPN-2572, ISPN-5471, 
ISPN-5473 and ISPN-5474
16:18:21 <jbossbot>	jira [ISPN-2572] "CacheException: Initial state 
transfer timed out for cache" reliably on AS7 testsuite [Resolved (Done) 
Bug, Blocker, Dan Berindei] https://issues.jboss.org/browse/ISPN-2572
16:18:21 <jbossbot>	jira [ISPN-5471] 
ConditionalOperationsConcurrentWriteSkewTest random failures [Pull 
Request Sent (Unresolved) Bug, Major, Unassigned] 
https://issues.jboss.org/browse/ISPN-5471
16:18:22 <jbossbot>	jira [ISPN-5473] Replace printStackTrace with 
logging in the test suite [Pull Request Sent (Unresolved) Task, Major, 
Dan Berindei] https://issues.jboss.org/browse/ISPN-5473
16:18:22 <jbossbot>	jira [ISPN-5474] Transactions created when applying 
state should never be replicated [Open (Unresolved) Bug, Critical, Dan 
Berindei] https://issues.jboss.org/browse/ISPN-5474
16:18:42 <dberindei>	coming up next, upgrade maven-surefire-plugin to 
try to fix ISPN-5472
16:18:43 <jbossbot>	jira [ISPN-5472] Surefire crashes during LevelDB 
test suite [Coding In Progress (Unresolved) Bug, Blocker, Dan Berindei] 
https://issues.jboss.org/browse/ISPN-5472
16:19:45 <dberindei>	and then go on with changing 
RpcManagerImpl/JGroupsTransport to not use a transport thread 
invokeRemotelyInFuture
16:20:00 <dberindei>	that's it from me, galderz next?
16:22:06 <galderz>	sure
16:22:10 <galderz>	#topic galder
16:22:55 <galderz>	last week I made further progress with the Java 8 API 
prototype, the proto8 git repo has it all so far, but needs to be 
documented further
16:23:06 <galderz>	in particular, i refined the way multiple elements 
are returned
16:23:22 <galderz>	so instead of having filter/reduce methods... use 
Observables for those
16:23:32 <galderz>	that has simplified things even further
16:23:54 <galderz>	this was done as i was trying to complete the jcache 
impl based on the new API
16:24:18 <galderz>	anyway, it needs a lot of javadocs and some minor things
16:24:38 <galderz>	other than that, some small issues came my way 
including ISPN-5449
16:24:39 <jbossbot>	jira [ISPN-5449] java.lang.ClassCastException: [B 
cannot be cast to org.infinispan.container.entries.CacheEntry [Coding In 
Progress (Unresolved) Bug, Major, Galder Zamarre?o] 
https://issues.jboss.org/browse/ISPN-5449
16:24:54 <galderz>	which I'm trying to replicate in a unit test as we 
speak...
16:25:11 <galderz>	i also fixed the Hibernate CI configurations
16:25:29 <galderz>	and was involved in ORM 4.3 work to get it to work 
with Infinispan 7.2.x
16:25:34 <galderz>	that seems to be ready now
16:25:56 <galderz>	this week: hopefully finish with the prototype and 
send it around for review
16:26:12 <galderz>	and work on fixes for ISPN-5449 and ISPN-5444
16:26:13 <jbossbot>	jira [ISPN-5449] java.lang.ClassCastException: [B 
cannot be cast to org.infinispan.container.entries.CacheEntry [Coding In 
Progress (Unresolved) Bug, Major, Galder Zamarre?o] 
https://issues.jboss.org/browse/ISPN-5449
16:26:13 <jbossbot>	jira [ISPN-5444] Filter/converters in server can't 
unmarshall custom cached classes [New (Unresolved) Bug, Major, Galder 
Zamarre?o] https://issues.jboss.org/browse/ISPN-5444
16:26:15 <galderz>	that's it from me
16:26:26 <galderz>	gustavonalle: next?
16:26:43 <gustavonalle>	galderz, y
16:26:47 <galderz>	oh btw, my xchat has died badly
16:27:03 <galderz>	it goes into hyper leak mode whenever i start it up, 
so trying other irc mechanisms
16:27:11 <gustavonalle>	#topic gustavonalle
16:27:22 <galderz>	so if I don't reply that probably means the 
notifications are not working well yet ;)
16:27:26 ---	tsegismont is now known as tsegismont_afk
16:27:29 <gustavonalle>	last week I worked mainly on JCache support over 
Hot Rod: ISPN-4955
16:27:29 <jbossbot>	jira [ISPN-4955] JCache implementation over HotRod 
[Resolved (Done) Feature Request, Major, Gustavo Fernandes] 
https://issues.jboss.org/browse/ISPN-4955
16:27:56 <gustavonalle>	That had a requirement of being able to sent an 
expiration in millisecond precision via Hot Rod, that was covered as 
part of ISPN-5298
16:27:57 <jbossbot>	jira [ISPN-5298] HotRod millisecond precision for 
lifespan/maxidle [Resolved (Done) Feature Request, Major, Gustavo 
Fernandes] https://issues.jboss.org/browse/ISPN-5298
16:28:28 <gustavonalle>	Now the time unit is part of the Hot Rod 
protocol for maxIdle and lifespan, using an extra byte
16:28:57 <gustavonalle>	I also looked into some failures on master due 
to the 8.0 version upd:
16:29:10 <gustavonalle>	In the query related modules: ISPN-5448
16:29:11 <jbossbot>	jira [ISPN-5448] NPE when configuring both SSL and 
authentication in the same fluid configuration API for HotRod [Resolved 
(Done) Bug, Major, Tristan Tarrant] 
https://issues.jboss.org/browse/ISPN-5448
16:29:32 <gustavonalle>	and in the server parsers: ISPN-5446
16:29:32 <jbossbot>	jira [ISPN-5446] Bump version, parsers and schemas 
to 8.0 [Resolved (Done) Task, Major, Tristan Tarrant] 
https://issues.jboss.org/browse/ISPN-5446
16:29:58 <ttarrant>	gustavonalle, my bad
16:30:18 <gustavonalle>	ops wrong number ISPN-5458
16:30:19 <jbossbot>	jira [ISPN-5458] Broken modules due to circular 
dependencies [Resolved (Done) Bug, Critical, Gustavo Fernandes] 
https://issues.jboss.org/browse/ISPN-5458
16:30:50 <gustavonalle>	Finally I started working on the remote iterator 
ISPN-5219
16:30:50 <jbossbot>	jira [ISPN-5219] Expose Distributed Iterators over 
HotRod [New (Unresolved) Feature Request, Major, Unassigned] 
https://issues.jboss.org/browse/ISPN-5219
16:31:18 <gustavonalle>	Got most of the client-side implemented (except 
for failover) and some bits of the server as well
16:32:45 <gustavonalle>	This week: carry on working on the remote iterator
16:33:12 <gustavonalle>	that's it from me
16:33:16 <gustavonalle>	who's next?
16:33:24 <gustavonalle>	sannegrinovero, ? vblagoje ?
16:33:29 <vblagoje>	sanne?
16:33:46 <vblagoje>	Ok I?ll go
16:33:56 <vblagoje>	#topic vblagoje
16:34:23 <vblagoje>	Last week I play with cache creation on CLI, not 
just cache per se but adding loader, eviction details and so on
16:34:55 <vblagoje>	The goal was to get a feel on how to create 
javascript API that can create a complex cache instance using CLI batches
16:35:58 <vblagoje>	I recommended to Tristan and PEdro that we use cache 
UI inspired by EAP but Catherine (our UI/X designer) was against that 
approach
16:36:25 <vblagoje>	She want to have it redesigned. According to her EAP 
UI/X people are also redesigning EAP create cache wizzards
16:36:55 <vblagoje>	In order to help her understand what is involved I 
wanted to create some sort of model reference she can easily refer to
16:37:12 <vblagoje>	It turns out Stewart Douglas from EAP team has 
already done that - 
http://wildscribe.github.io/Wildfly/8.2.0.Final/index.html
16:37:12 <jbossbot>	Title: Wildfly Model Reference
16:37:32 <vblagoje>	I then proceeded to understand how to make the same 
HTML reference for Infinispan server
16:38:12 <vblagoje>	And I did that, so now I would like to have us 
generate this model reference not just for Catherine but for wider audience
16:38:27 <vblagoje>	Will talk to Tristan about today
16:39:04 <vblagoje>	This week I want to start writing javascript cache 
create code while Catherine works on UI cache create wizzard
16:39:22 <vblagoje>	And then we?ll continue to push onward on that front
16:39:28 <vblagoje>	That?s all from me
16:39:43 <vblagoje>	wburns?
16:39:53 <wburns>	vblagoje: sure
16:40:22 <wburns>	last week I finally got in 
https://github.com/infinispan/infinispan/pull/3467
16:40:22 <jbossbot>	git pull req [infinispan] (open) wburns ISPN-5345 
Allow eviction for based on approximation of size compared to 
https://github.com/infinispan/infinispan/pull/3467
16:40:22 <jbossbot>	jira [ISPN-5345] Allow eviction for based on 
approximation of size compared to element count [Pull Request Sent 
(Unresolved) Enhancement, Major, William Burns] 
https://issues.jboss.org/browse/ISPN-5345
16:40:51 <wburns>	did some last minute reviews as well
16:41:06 <wburns>	for the build(s) last week
16:41:20 <wburns>	this morning I have been looking at ISPN-5449
16:41:21 <jbossbot>	jira [ISPN-5449] java.lang.ClassCastException: [B 
cannot be cast to org.infinispan.container.entries.CacheEntry [Coding In 
Progress (Unresolved) Bug, Major, Galder Zamarre?o] 
https://issues.jboss.org/browse/ISPN-5449
16:41:28 <wburns>	with galderz
16:41:47 <wburns>	and I found a timing issue with L1 when using 
getCacheEntry - I should be making a PR in just a little bit
16:42:27 <wburns>	and then I should be able to get back to ISPN-5293 - 
hope to get something bare bones done this week
16:42:27 <jbossbot>	jira [ISPN-5293] Create generic execution framework 
from EntryIterator [Coding In Progress (Unresolved) Feature Request, 
Major, William Burns] https://issues.jboss.org/browse/ISPN-5293
16:42:42 <wburns>	but I will be on PTO on Thu/Fri and holiday on Mon 
just give you guys a heads up
16:43:04 <wburns>	that is it for me ttarrant
16:43:09 <ttarrant>	thanks to all
16:43:15 <ttarrant>	#endmeeting ?

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

From afield at redhat.com  Mon May 18 10:52:32 2015
From: afield at redhat.com (Alan Field)
Date: Mon, 18 May 2015 10:52:32 -0400 (EDT)
Subject: [infinispan-dev] =?utf-8?q?Welcome_Martin_Vr=C3=A1bel_to_the_JDG_?=
	=?utf-8?q?QE_team=2E=2E=2E?=
In-Reply-To: <523730795.740596.1431956623594.JavaMail.zimbra@redhat.com>
Message-ID: <402769993.789649.1431960752521.JavaMail.zimbra@redhat.com>

Hey,

We have a new inter starting on the JDG QE team. Martin Vr?bel will be working with the remotely from Prague where he is at Czech Technical University.

Please welcome Martin to the team!

Thanks,
Alan

BTW, Martin picked a position on Infinispan over Kubernetes!

-- 
Alan Field
Supervisor and Principal Quality Engineer - JBoss Data Grid
T: (919) 890-8932 | Ext. 8148932


From sanne at infinispan.org  Mon May 18 11:00:37 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 18 May 2015 16:00:37 +0100
Subject: [infinispan-dev]
	=?utf-8?q?Welcome_Martin_Vr=C3=A1bel_to_the_JDG_?=
	=?utf-8?q?QE_team=2E=2E=2E?=
In-Reply-To: <402769993.789649.1431960752521.JavaMail.zimbra@redhat.com>
References: <523730795.740596.1431956623594.JavaMail.zimbra@redhat.com>
	<402769993.789649.1431960752521.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO02FJTnmDsUpimKz0DUwDzxUXrU+E9B2p7-Nn0y1g7aFQ@mail.gmail.com>

Welcome Martin!

On 18 May 2015 at 15:52, Alan Field <afield at redhat.com> wrote:
> Hey,
>
> We have a new inter starting on the JDG QE team. Martin Vr?bel will be working with the remotely from Prague where he is at Czech Technical University.
>
> Please welcome Martin to the team!
>
> Thanks,
> Alan
>
> BTW, Martin picked a position on Infinispan over Kubernetes!
>
> --
> Alan Field
> Supervisor and Principal Quality Engineer - JBoss Data Grid
> T: (919) 890-8932 | Ext. 8148932
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From wfink at redhat.com  Tue May 19 02:01:35 2015
From: wfink at redhat.com (Wolf-Dieter Fink)
Date: Tue, 19 May 2015 08:01:35 +0200
Subject: [infinispan-dev]
 =?utf-8?q?Welcome_Martin_Vr=C3=A1bel_to_the_JDG_?=
 =?utf-8?q?QE_team=2E=2E=2E?=
In-Reply-To: <402769993.789649.1431960752521.JavaMail.zimbra@redhat.com>
References: <402769993.789649.1431960752521.JavaMail.zimbra@redhat.com>
Message-ID: <555AD1BF.2080705@redhat.com>

Hello Martin

welcome to the team

- Wolf

On 18/05/15 16:52, Alan Field wrote:
> Hey,
>
> We have a new inter starting on the JDG QE team. Martin Vr?bel will be working with the remotely from Prague where he is at Czech Technical University.
>
> Please welcome Martin to the team!
>
> Thanks,
> Alan
>
> BTW, Martin picked a position on Infinispan over Kubernetes!
>


From rory.odonnell at oracle.com  Tue May 19 04:22:56 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 19 May 2015 09:22:56 +0100
Subject: [infinispan-dev] Early Access builds for JDK 9 b64 and JDK 8u60 b15
 are available on java.net
Message-ID: <555AF2E0.6070106@oracle.com>


Hi Galder,

Early Access build for JDK 9 b64 <https://jdk9.java.net/download/> is 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/jdk9/changes/jdk9-b64.html>
The JDK 9 schedule of record is available on the JDK 9 Project page: 
http://openjdk.java.net/projects/jdk9


Early Access build for JDK 8u60 b15 <http://jdk8.java.net/download.html> 
is available on java.net, summary of changes are listed here. 
<http://www.java.net/download/jdk8u60/changes/jdk8u60-b15.html>
Note with 8077220 in 8u60 b12 , we are disabling the RC4 cipher suite by 
default.

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

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/20150519/028f916b/attachment.html 

From galder at redhat.com  Tue May 19 08:13:28 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 19 May 2015 14:13:28 +0200
Subject: [infinispan-dev] missing "int
	org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()"
	& NoSuchMethodError running hibernate-infinispan tests with
	Infinispan 7.2.1
In-Reply-To: <555604E8.9080302@redhat.com>
References: <555604E8.9080302@redhat.com>
Message-ID: <05B68EE8-9132-425C-B854-25F19F3652BB@redhat.com>

As far as 2LC is concerned, this is not problematic for 2LC users because except in testing, we never check this value in the production code. IOW, in production we set max entries but we don't query it, so it's not problematic. In testing, we verify that the cache's eviction max entries is the one we've configured via the Hibernate/JPA configuration, but that's it.

> On 15 May 2015, at 16:38, Scott Marlow <smarlow at redhat.com> wrote:
> 
> Applications that compile against Infinispan 6.x, will expect that 
> org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() 
> returns an int but when they run against Infinispan 7.x, they will not 
> find this method (since maxEntries() returns a long).
> 
> Is this a known bug or issue on Infinispan 7.x?  Can you recommend a 
> solution or workaround for applications that currently depend on 
> maxEntries returning an int but aren't ready to recompile against 
> Infinispan 7?
> 
> Also see the original discussion from last night on hibernate-dev ml [1][2].
> 
> Scott
> 
> [1] http://lists.jboss.org/pipermail/hibernate-dev/2015-May/012715.html
> [2] http://lists.jboss.org/pipermail/hibernate-dev/2015-May/012725.html
> _______________________________________________
> 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  Tue May 19 08:20:44 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 19 May 2015 14:20:44 +0200
Subject: [infinispan-dev]
 =?utf-8?q?=5Binfinispan-internal=5D_Welcome_Mart?=
 =?utf-8?q?in_Vr=C3=A1bel_to_the_JDG_QE_team=2E=2E=2E?=
In-Reply-To: <402769993.789649.1431960752521.JavaMail.zimbra@redhat.com>
References: <402769993.789649.1431960752521.JavaMail.zimbra@redhat.com>
Message-ID: <78C92976-8998-4237-BA05-70414D47AFD4@redhat.com>

Welcome Martin!!! :D

> On 18 May 2015, at 16:52, Alan Field <afield at redhat.com> wrote:
> 
> Hey,
> 
> We have a new inter starting on the JDG QE team. Martin Vr?bel will be working with the remotely from Prague where he is at Czech Technical University.
> 
> Please welcome Martin to the team!
> 
> Thanks,
> Alan
> 
> BTW, Martin picked a position on Infinispan over Kubernetes!
> 
> -- 
> Alan Field
> Supervisor and Principal Quality Engineer - JBoss Data Grid
> T: (919) 890-8932 | Ext. 8148932
> 


--
Galder Zamarre?o
galder at redhat.com






From galder at redhat.com  Fri May 22 02:41:07 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Fri, 22 May 2015 08:41:07 +0200
Subject: [infinispan-dev] Configuration changes proposal for 8.0
In-Reply-To: <CA+nfvwQTDyaJkQz78YBcv1AP6wwbJOa-XC-mDLM4sbUnXnmgbw@mail.gmail.com>
References: <55537EFC.3090702@redhat.com> <555384CE.9030208@infinispan.org>
	<CA+nfvwQTDyaJkQz78YBcv1AP6wwbJOa-XC-mDLM4sbUnXnmgbw@mail.gmail.com>
Message-ID: <8804B1BF-D353-4542-87FD-7A7A566823EB@redhat.com>


> On 14 May 2015, at 16:40, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
> On Wed, May 13, 2015 at 8:07 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>> Hi,
>> 
>> comments inline
>> 
>> Pedro
>> 
>> On 05/13/2015 05:42 PM, Tristan Tarrant wrote:
>>> Hi all,
>>> 
>>> this is a list of proposed changes for 8.x that affect configuration and
>>> default behaviour. We built this list last year, but never acted upon
>>> it, but now I believe it's time to do these changes. Please
>>> comment/add/remove as you think is appropriate.
>>> 
>>> - Make IGNORE_RETURN_VALUES the default
>> 
>> hmmm, not sure about it. it only makes sense for put(k,v) and
>> remove(k,v) since all other write operations are conditional (i.e. need
>> the previous value and no optimization can be made)
> 
> For putIfAbsent(k, v) it also helps if you don't have to return the
> previous value, and I would expect most write operations to be put(k,
> v) anyway.

AFAIK, the main objective of IGNORE_RETURN_VALUES has been to avoid having to check what the previous value was. Even if putIfAbsent() would not return the previous value, it needs to check if put happens for the first time, so there's an attempt to retrieve the previous value, if there's any, from the cluster.

> On the other hand, why not adopt the JCache interface and stop implementing Map?

^ The Java 8 API I've been working on tries to make this easier to achieve (and update will be available in the next week or so!), but I don't think we can abandon ConcurrentMap just yet...

> 
>> 
>>> - Drop asymmetric marshalling [1]
> 
> +1, but it should be *asynchronous* marshalling.
> 
>>> - Remove/change some transaction options [2]
>>> - ReplicationQueue - one should not be allowed to specify it as an instance
>>> - ReplicationQueue - enabled should be implicit ? interval > 0 ||
>>> queueSize > 0. Also flushing when queueSize has been reached should
>>> happen async.
>> 
>> Can we remove the ReplicationQueue? First, it does not have any benefit
>> (JGroups already bundles the message and the Network can do it too) and
>> second, it is not more efficient (when the message is delivered, we
>> process the commands sequentially. So, if the first command blocks, the
>> other commands are not processed until it finished). Third, it is
>> complex if you have commands with multiple delivers orders (no order,
>> FIFO, total)
> 
> +1, the replication queue has the same purpose as the bundler in
> JGroups. And while the JGroups bundler has multiple options that keep
> evolving, our replication queue still has the same algorithm it had in
> 4.0.
> 
>> 
>>> - AsyncStoreConfiguration.shutdownTimeout -
>>> force-immediate=?false[default]? (destructive)
>>>                     .flushLockTimeout - remove as it is no longer used
>>> - BackupConfigurationBuilder - remove getters and implicitly set
>>> BackupFailurePolicy
>>> - allow setting failurePolicy by class not by string
>>> - Reconsider usefulness of ClusterLoader
>> 
>> didn't get this one ^
> 
> -1 from me to remove the ClusterLoader, unless we replace it with a
> better integrated alternative for invalidation mode.
> 
>> 
>>> - DataContainer.properties - to be removed
>> 
>> so, we will not allow any custom implementation to be configured? or I
>> miss something?
>> 
>>> - ExpirationConfiguration.reaperEnabled should be removed and the
>>> interval value used instead
>>> - HashConfiguration - remove deprecated elements
> 
> Here I would suggest also replacing the Hash with another interface:
> https://issues.jboss.org/browse/ISPN-5465
> 
>>> - L1Configuration to fail if the reaper frequency interval is less or
>>> equal than 0
>>> - LockingConfigurationBuilder.useLockStriping - remove it &
>>> writeSkewCheck enabled by default and removed
>> 
> 
> +1 to remove lock striping
> 
>> write skew check should be moved to Transactions. It is the only place
>> in which it makes sense
> 
> +1 to enable writeSkewCheck by default
> +1 to remove it from the locking configuration. But I think "write
> skew disabled" should be another locking mode, perhaps called
> LAST_WRITE_WINS.
> 
>> 
>>> - SingletonStore - pushStateWhenCoordinator implicit by pushStateTimeout
>>> -> flushTimeout
>>> - StateTransfer.fetchInMemoryState -> renamed to enabled
> 
> +1
> 
>>> - StoreAsBinary - remove ?enabled? and reply on storeKey/storeBinary +
>>> remove deprecation
>>> - remove deprecations from TransactionConfiguration and remove
>>> use1PcForAutCommitTx
> 
> +1
> 
>>> - VersioningConfiguration.enabled should be computed based on the scheme
>>> and removed
> 
> +1
> 
>>> - Version - remove the version fields and populate them through a mvn script
>>> - SerializationConfigurationBuilder - consider removing the version field
> 
> +1 to remove it, the javadoc there suggests we support
> interoperability between different Infinispan versions and that's
> still too onerous for us at this point.
> 
>>> - ShutdownConfiguration - to be removed, confirm with an email
>>> - TransportConfiguration.distributedSyncTimeout -> global RPC timeout
> 
> +1
> 
>>> - strictPeerToPeer should go as it is deprecated
> 
> +1
> 
>>> 
>> 
>> another suggestion:
>> 
>> - Transaction, remove the transaction_protocol and add TOTAL as an
>> option for locking_mode
>> 
>> *or*
>> 
>> - Transaction, remove the transaction_protocol
>> - Locking, add locking mode with LOCK and TOTAL_ORDER options (since
>> I'll probably implement total order based non transactional caches)
> 
> I don't feel like TOTAL belongs to the locking element. Since total
> order is only relevant in clustered caches, how about making it an
> alternative clustering mode?
> 
> <clustering mode="SYNC|ASYNC|TOTAL"/>
> 
> 
>> 
>>> 
>>> [1] https://issues.jboss.org/browse/ISPN-2939
>>> [2] https://issues.jboss.org/browse/ISPN-3927
>>> 
> 
> _______________________________________________
> 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 dan.berindei at gmail.com  Fri May 22 03:54:37 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Fri, 22 May 2015 10:54:37 +0300
Subject: [infinispan-dev] Configuration changes proposal for 8.0
In-Reply-To: <8804B1BF-D353-4542-87FD-7A7A566823EB@redhat.com>
References: <55537EFC.3090702@redhat.com> <555384CE.9030208@infinispan.org>
	<CA+nfvwQTDyaJkQz78YBcv1AP6wwbJOa-XC-mDLM4sbUnXnmgbw@mail.gmail.com>
	<8804B1BF-D353-4542-87FD-7A7A566823EB@redhat.com>
Message-ID: <CA+nfvwQRkT+F+BEoysi1CakCjFZTYDz4mhrJnzUA_7HOS=kbJw@mail.gmail.com>

On Fri, May 22, 2015 at 9:41 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>
>> On 14 May 2015, at 16:40, Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>> On Wed, May 13, 2015 at 8:07 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>>> Hi,
>>>
>>> comments inline
>>>
>>> Pedro
>>>
>>> On 05/13/2015 05:42 PM, Tristan Tarrant wrote:
>>>> Hi all,
>>>>
>>>> this is a list of proposed changes for 8.x that affect configuration and
>>>> default behaviour. We built this list last year, but never acted upon
>>>> it, but now I believe it's time to do these changes. Please
>>>> comment/add/remove as you think is appropriate.
>>>>
>>>> - Make IGNORE_RETURN_VALUES the default
>>>
>>> hmmm, not sure about it. it only makes sense for put(k,v) and
>>> remove(k,v) since all other write operations are conditional (i.e. need
>>> the previous value and no optimization can be made)
>>
>> For putIfAbsent(k, v) it also helps if you don't have to return the
>> previous value, and I would expect most write operations to be put(k,
>> v) anyway.
>
> AFAIK, the main objective of IGNORE_RETURN_VALUES has been to avoid having to check what the previous value was. Even if putIfAbsent() would not return the previous value, it needs to check if put happens for the first time, so there's an attempt to retrieve the previous value, if there's any, from the cluster.

In transactions, yes, you still have to retrieve the value from the
owners, because the originator makes the decision. But in a
non-transactional cache, the primary owner wouldn't have to ship the
previous value to the originator.

>
>> On the other hand, why not adopt the JCache interface and stop implementing Map?
>
> ^ The Java 8 API I've been working on tries to make this easier to achieve (and update will be available in the next week or so!), but I don't think we can abandon ConcurrentMap just yet...
>

Ok, I might have exaggerated with "stop implementing Map", but
IGNORE_RETURN_VALUES won't matter if we make JCache the
default/recommended way to access the cache in 8.0.

>>
>>>
>>>> - Drop asymmetric marshalling [1]
>>
>> +1, but it should be *asynchronous* marshalling.
>>
>>>> - Remove/change some transaction options [2]
>>>> - ReplicationQueue - one should not be allowed to specify it as an instance
>>>> - ReplicationQueue - enabled should be implicit ? interval > 0 ||
>>>> queueSize > 0. Also flushing when queueSize has been reached should
>>>> happen async.
>>>
>>> Can we remove the ReplicationQueue? First, it does not have any benefit
>>> (JGroups already bundles the message and the Network can do it too) and
>>> second, it is not more efficient (when the message is delivered, we
>>> process the commands sequentially. So, if the first command blocks, the
>>> other commands are not processed until it finished). Third, it is
>>> complex if you have commands with multiple delivers orders (no order,
>>> FIFO, total)
>>
>> +1, the replication queue has the same purpose as the bundler in
>> JGroups. And while the JGroups bundler has multiple options that keep
>> evolving, our replication queue still has the same algorithm it had in
>> 4.0.
>>
>>>
>>>> - AsyncStoreConfiguration.shutdownTimeout -
>>>> force-immediate=?false[default]? (destructive)
>>>>                     .flushLockTimeout - remove as it is no longer used
>>>> - BackupConfigurationBuilder - remove getters and implicitly set
>>>> BackupFailurePolicy
>>>> - allow setting failurePolicy by class not by string
>>>> - Reconsider usefulness of ClusterLoader
>>>
>>> didn't get this one ^
>>
>> -1 from me to remove the ClusterLoader, unless we replace it with a
>> better integrated alternative for invalidation mode.
>>
>>>
>>>> - DataContainer.properties - to be removed
>>>
>>> so, we will not allow any custom implementation to be configured? or I
>>> miss something?
>>>
>>>> - ExpirationConfiguration.reaperEnabled should be removed and the
>>>> interval value used instead
>>>> - HashConfiguration - remove deprecated elements
>>
>> Here I would suggest also replacing the Hash with another interface:
>> https://issues.jboss.org/browse/ISPN-5465
>>
>>>> - L1Configuration to fail if the reaper frequency interval is less or
>>>> equal than 0
>>>> - LockingConfigurationBuilder.useLockStriping - remove it &
>>>> writeSkewCheck enabled by default and removed
>>>
>>
>> +1 to remove lock striping
>>
>>> write skew check should be moved to Transactions. It is the only place
>>> in which it makes sense
>>
>> +1 to enable writeSkewCheck by default
>> +1 to remove it from the locking configuration. But I think "write
>> skew disabled" should be another locking mode, perhaps called
>> LAST_WRITE_WINS.
>>
>>>
>>>> - SingletonStore - pushStateWhenCoordinator implicit by pushStateTimeout
>>>> -> flushTimeout
>>>> - StateTransfer.fetchInMemoryState -> renamed to enabled
>>
>> +1
>>
>>>> - StoreAsBinary - remove ?enabled? and reply on storeKey/storeBinary +
>>>> remove deprecation
>>>> - remove deprecations from TransactionConfiguration and remove
>>>> use1PcForAutCommitTx
>>
>> +1
>>
>>>> - VersioningConfiguration.enabled should be computed based on the scheme
>>>> and removed
>>
>> +1
>>
>>>> - Version - remove the version fields and populate them through a mvn script
>>>> - SerializationConfigurationBuilder - consider removing the version field
>>
>> +1 to remove it, the javadoc there suggests we support
>> interoperability between different Infinispan versions and that's
>> still too onerous for us at this point.
>>
>>>> - ShutdownConfiguration - to be removed, confirm with an email
>>>> - TransportConfiguration.distributedSyncTimeout -> global RPC timeout
>>
>> +1
>>
>>>> - strictPeerToPeer should go as it is deprecated
>>
>> +1
>>
>>>>
>>>
>>> another suggestion:
>>>
>>> - Transaction, remove the transaction_protocol and add TOTAL as an
>>> option for locking_mode
>>>
>>> *or*
>>>
>>> - Transaction, remove the transaction_protocol
>>> - Locking, add locking mode with LOCK and TOTAL_ORDER options (since
>>> I'll probably implement total order based non transactional caches)
>>
>> I don't feel like TOTAL belongs to the locking element. Since total
>> order is only relevant in clustered caches, how about making it an
>> alternative clustering mode?
>>
>> <clustering mode="SYNC|ASYNC|TOTAL"/>
>>
>>
>>>
>>>>
>>>> [1] https://issues.jboss.org/browse/ISPN-2939
>>>> [2] https://issues.jboss.org/browse/ISPN-3927
>>>>
>>
>> _______________________________________________
>> 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


From galder at redhat.com  Fri May 22 05:27:02 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Fri, 22 May 2015 11:27:02 +0200
Subject: [infinispan-dev] Configuration changes proposal for 8.0
In-Reply-To: <CA+nfvwQRkT+F+BEoysi1CakCjFZTYDz4mhrJnzUA_7HOS=kbJw@mail.gmail.com>
References: <55537EFC.3090702@redhat.com> <555384CE.9030208@infinispan.org>
	<CA+nfvwQTDyaJkQz78YBcv1AP6wwbJOa-XC-mDLM4sbUnXnmgbw@mail.gmail.com>
	<8804B1BF-D353-4542-87FD-7A7A566823EB@redhat.com>
	<CA+nfvwQRkT+F+BEoysi1CakCjFZTYDz4mhrJnzUA_7HOS=kbJw@mail.gmail.com>
Message-ID: <E80047DF-2FBE-422E-8E34-4ACC1B0CCD06@redhat.com>


> On 22 May 2015, at 09:54, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
> On Fri, May 22, 2015 at 9:41 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>> 
>>> On 14 May 2015, at 16:40, Dan Berindei <dan.berindei at gmail.com> wrote:
>>> 
>>> On Wed, May 13, 2015 at 8:07 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>>>> Hi,
>>>> 
>>>> comments inline
>>>> 
>>>> Pedro
>>>> 
>>>> On 05/13/2015 05:42 PM, Tristan Tarrant wrote:
>>>>> Hi all,
>>>>> 
>>>>> this is a list of proposed changes for 8.x that affect configuration and
>>>>> default behaviour. We built this list last year, but never acted upon
>>>>> it, but now I believe it's time to do these changes. Please
>>>>> comment/add/remove as you think is appropriate.
>>>>> 
>>>>> - Make IGNORE_RETURN_VALUES the default
>>>> 
>>>> hmmm, not sure about it. it only makes sense for put(k,v) and
>>>> remove(k,v) since all other write operations are conditional (i.e. need
>>>> the previous value and no optimization can be made)
>>> 
>>> For putIfAbsent(k, v) it also helps if you don't have to return the
>>> previous value, and I would expect most write operations to be put(k,
>>> v) anyway.
>> 
>> AFAIK, the main objective of IGNORE_RETURN_VALUES has been to avoid having to check what the previous value was. Even if putIfAbsent() would not return the previous value, it needs to check if put happens for the first time, so there's an attempt to retrieve the previous value, if there's any, from the cluster.
> 
> In transactions, yes, you still have to retrieve the value from the
> owners, because the originator makes the decision. But in a
> non-transactional cache, the primary owner wouldn't have to ship the
> previous value to the originator.

Well, but the primary owner would need to ship information to the originator on whether the cache entry exists or not. Sure, there's a difference between sending back a Boolean vs a V if the V is large, but you still pay the penalty of network.

> 
>> 
>>> On the other hand, why not adopt the JCache interface and stop implementing Map?
>> 
>> ^ The Java 8 API I've been working on tries to make this easier to achieve (and update will be available in the next week or so!), but I don't think we can abandon ConcurrentMap just yet...
>> 
> 
> Ok, I might have exaggerated with "stop implementing Map", but
> IGNORE_RETURN_VALUES won't matter if we make JCache the
> default/recommended way to access the cache in 8.0.
> 
>>> 
>>>> 
>>>>> - Drop asymmetric marshalling [1]
>>> 
>>> +1, but it should be *asynchronous* marshalling.
>>> 
>>>>> - Remove/change some transaction options [2]
>>>>> - ReplicationQueue - one should not be allowed to specify it as an instance
>>>>> - ReplicationQueue - enabled should be implicit ? interval > 0 ||
>>>>> queueSize > 0. Also flushing when queueSize has been reached should
>>>>> happen async.
>>>> 
>>>> Can we remove the ReplicationQueue? First, it does not have any benefit
>>>> (JGroups already bundles the message and the Network can do it too) and
>>>> second, it is not more efficient (when the message is delivered, we
>>>> process the commands sequentially. So, if the first command blocks, the
>>>> other commands are not processed until it finished). Third, it is
>>>> complex if you have commands with multiple delivers orders (no order,
>>>> FIFO, total)
>>> 
>>> +1, the replication queue has the same purpose as the bundler in
>>> JGroups. And while the JGroups bundler has multiple options that keep
>>> evolving, our replication queue still has the same algorithm it had in
>>> 4.0.
>>> 
>>>> 
>>>>> - AsyncStoreConfiguration.shutdownTimeout -
>>>>> force-immediate=?false[default]? (destructive)
>>>>>                    .flushLockTimeout - remove as it is no longer used
>>>>> - BackupConfigurationBuilder - remove getters and implicitly set
>>>>> BackupFailurePolicy
>>>>> - allow setting failurePolicy by class not by string
>>>>> - Reconsider usefulness of ClusterLoader
>>>> 
>>>> didn't get this one ^
>>> 
>>> -1 from me to remove the ClusterLoader, unless we replace it with a
>>> better integrated alternative for invalidation mode.
>>> 
>>>> 
>>>>> - DataContainer.properties - to be removed
>>>> 
>>>> so, we will not allow any custom implementation to be configured? or I
>>>> miss something?
>>>> 
>>>>> - ExpirationConfiguration.reaperEnabled should be removed and the
>>>>> interval value used instead
>>>>> - HashConfiguration - remove deprecated elements
>>> 
>>> Here I would suggest also replacing the Hash with another interface:
>>> https://issues.jboss.org/browse/ISPN-5465
>>> 
>>>>> - L1Configuration to fail if the reaper frequency interval is less or
>>>>> equal than 0
>>>>> - LockingConfigurationBuilder.useLockStriping - remove it &
>>>>> writeSkewCheck enabled by default and removed
>>>> 
>>> 
>>> +1 to remove lock striping
>>> 
>>>> write skew check should be moved to Transactions. It is the only place
>>>> in which it makes sense
>>> 
>>> +1 to enable writeSkewCheck by default
>>> +1 to remove it from the locking configuration. But I think "write
>>> skew disabled" should be another locking mode, perhaps called
>>> LAST_WRITE_WINS.
>>> 
>>>> 
>>>>> - SingletonStore - pushStateWhenCoordinator implicit by pushStateTimeout
>>>>> -> flushTimeout
>>>>> - StateTransfer.fetchInMemoryState -> renamed to enabled
>>> 
>>> +1
>>> 
>>>>> - StoreAsBinary - remove ?enabled? and reply on storeKey/storeBinary +
>>>>> remove deprecation
>>>>> - remove deprecations from TransactionConfiguration and remove
>>>>> use1PcForAutCommitTx
>>> 
>>> +1
>>> 
>>>>> - VersioningConfiguration.enabled should be computed based on the scheme
>>>>> and removed
>>> 
>>> +1
>>> 
>>>>> - Version - remove the version fields and populate them through a mvn script
>>>>> - SerializationConfigurationBuilder - consider removing the version field
>>> 
>>> +1 to remove it, the javadoc there suggests we support
>>> interoperability between different Infinispan versions and that's
>>> still too onerous for us at this point.
>>> 
>>>>> - ShutdownConfiguration - to be removed, confirm with an email
>>>>> - TransportConfiguration.distributedSyncTimeout -> global RPC timeout
>>> 
>>> +1
>>> 
>>>>> - strictPeerToPeer should go as it is deprecated
>>> 
>>> +1
>>> 
>>>>> 
>>>> 
>>>> another suggestion:
>>>> 
>>>> - Transaction, remove the transaction_protocol and add TOTAL as an
>>>> option for locking_mode
>>>> 
>>>> *or*
>>>> 
>>>> - Transaction, remove the transaction_protocol
>>>> - Locking, add locking mode with LOCK and TOTAL_ORDER options (since
>>>> I'll probably implement total order based non transactional caches)
>>> 
>>> I don't feel like TOTAL belongs to the locking element. Since total
>>> order is only relevant in clustered caches, how about making it an
>>> alternative clustering mode?
>>> 
>>> <clustering mode="SYNC|ASYNC|TOTAL"/>
>>> 
>>> 
>>>> 
>>>>> 
>>>>> [1] https://issues.jboss.org/browse/ISPN-2939
>>>>> [2] https://issues.jboss.org/browse/ISPN-3927
>>>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> 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 sanne at infinispan.org  Fri May 22 18:26:37 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Sat, 23 May 2015 00:26:37 +0200
Subject: [infinispan-dev] Configuration changes proposal for 8.0
In-Reply-To: <E80047DF-2FBE-422E-8E34-4ACC1B0CCD06@redhat.com>
References: <55537EFC.3090702@redhat.com> <555384CE.9030208@infinispan.org>
	<CA+nfvwQTDyaJkQz78YBcv1AP6wwbJOa-XC-mDLM4sbUnXnmgbw@mail.gmail.com>
	<8804B1BF-D353-4542-87FD-7A7A566823EB@redhat.com>
	<CA+nfvwQRkT+F+BEoysi1CakCjFZTYDz4mhrJnzUA_7HOS=kbJw@mail.gmail.com>
	<E80047DF-2FBE-422E-8E34-4ACC1B0CCD06@redhat.com>
Message-ID: <CAFm4XO3PzA9o+kQOyFpQERjmmcKXUDn3zho8ZaXuztf9VwuDow@mail.gmail.com>

I can't think of a useful application for doing a put-if-absent without
having it return a success / fail boolean.

Same for replacement and other atomic conditional operations: that boolean
return is important to have.
 On 22 May 2015 11:29, "Galder Zamarre?o" <galder at redhat.com> wrote:

>
> > On 22 May 2015, at 09:54, Dan Berindei <dan.berindei at gmail.com> wrote:
> >
> > On Fri, May 22, 2015 at 9:41 AM, Galder Zamarre?o <galder at redhat.com>
> wrote:
> >>
> >>> On 14 May 2015, at 16:40, Dan Berindei <dan.berindei at gmail.com> wrote:
> >>>
> >>> On Wed, May 13, 2015 at 8:07 PM, Pedro Ruivo <pedro at infinispan.org>
> wrote:
> >>>> Hi,
> >>>>
> >>>> comments inline
> >>>>
> >>>> Pedro
> >>>>
> >>>> On 05/13/2015 05:42 PM, Tristan Tarrant wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> this is a list of proposed changes for 8.x that affect configuration
> and
> >>>>> default behaviour. We built this list last year, but never acted upon
> >>>>> it, but now I believe it's time to do these changes. Please
> >>>>> comment/add/remove as you think is appropriate.
> >>>>>
> >>>>> - Make IGNORE_RETURN_VALUES the default
> >>>>
> >>>> hmmm, not sure about it. it only makes sense for put(k,v) and
> >>>> remove(k,v) since all other write operations are conditional (i.e.
> need
> >>>> the previous value and no optimization can be made)
> >>>
> >>> For putIfAbsent(k, v) it also helps if you don't have to return the
> >>> previous value, and I would expect most write operations to be put(k,
> >>> v) anyway.
> >>
> >> AFAIK, the main objective of IGNORE_RETURN_VALUES has been to avoid
> having to check what the previous value was. Even if putIfAbsent() would
> not return the previous value, it needs to check if put happens for the
> first time, so there's an attempt to retrieve the previous value, if
> there's any, from the cluster.
> >
> > In transactions, yes, you still have to retrieve the value from the
> > owners, because the originator makes the decision. But in a
> > non-transactional cache, the primary owner wouldn't have to ship the
> > previous value to the originator.
>
> Well, but the primary owner would need to ship information to the
> originator on whether the cache entry exists or not. Sure, there's a
> difference between sending back a Boolean vs a V if the V is large, but you
> still pay the penalty of network.
>
> >
> >>
> >>> On the other hand, why not adopt the JCache interface and stop
> implementing Map?
> >>
> >> ^ The Java 8 API I've been working on tries to make this easier to
> achieve (and update will be available in the next week or so!), but I don't
> think we can abandon ConcurrentMap just yet...
> >>
> >
> > Ok, I might have exaggerated with "stop implementing Map", but
> > IGNORE_RETURN_VALUES won't matter if we make JCache the
> > default/recommended way to access the cache in 8.0.
> >
> >>>
> >>>>
> >>>>> - Drop asymmetric marshalling [1]
> >>>
> >>> +1, but it should be *asynchronous* marshalling.
> >>>
> >>>>> - Remove/change some transaction options [2]
> >>>>> - ReplicationQueue - one should not be allowed to specify it as an
> instance
> >>>>> - ReplicationQueue - enabled should be implicit ? interval > 0 ||
> >>>>> queueSize > 0. Also flushing when queueSize has been reached should
> >>>>> happen async.
> >>>>
> >>>> Can we remove the ReplicationQueue? First, it does not have any
> benefit
> >>>> (JGroups already bundles the message and the Network can do it too)
> and
> >>>> second, it is not more efficient (when the message is delivered, we
> >>>> process the commands sequentially. So, if the first command blocks,
> the
> >>>> other commands are not processed until it finished). Third, it is
> >>>> complex if you have commands with multiple delivers orders (no order,
> >>>> FIFO, total)
> >>>
> >>> +1, the replication queue has the same purpose as the bundler in
> >>> JGroups. And while the JGroups bundler has multiple options that keep
> >>> evolving, our replication queue still has the same algorithm it had in
> >>> 4.0.
> >>>
> >>>>
> >>>>> - AsyncStoreConfiguration.shutdownTimeout -
> >>>>> force-immediate=?false[default]? (destructive)
> >>>>>                    .flushLockTimeout - remove as it is no longer used
> >>>>> - BackupConfigurationBuilder - remove getters and implicitly set
> >>>>> BackupFailurePolicy
> >>>>> - allow setting failurePolicy by class not by string
> >>>>> - Reconsider usefulness of ClusterLoader
> >>>>
> >>>> didn't get this one ^
> >>>
> >>> -1 from me to remove the ClusterLoader, unless we replace it with a
> >>> better integrated alternative for invalidation mode.
> >>>
> >>>>
> >>>>> - DataContainer.properties - to be removed
> >>>>
> >>>> so, we will not allow any custom implementation to be configured? or I
> >>>> miss something?
> >>>>
> >>>>> - ExpirationConfiguration.reaperEnabled should be removed and the
> >>>>> interval value used instead
> >>>>> - HashConfiguration - remove deprecated elements
> >>>
> >>> Here I would suggest also replacing the Hash with another interface:
> >>> https://issues.jboss.org/browse/ISPN-5465
> >>>
> >>>>> - L1Configuration to fail if the reaper frequency interval is less or
> >>>>> equal than 0
> >>>>> - LockingConfigurationBuilder.useLockStriping - remove it &
> >>>>> writeSkewCheck enabled by default and removed
> >>>>
> >>>
> >>> +1 to remove lock striping
> >>>
> >>>> write skew check should be moved to Transactions. It is the only place
> >>>> in which it makes sense
> >>>
> >>> +1 to enable writeSkewCheck by default
> >>> +1 to remove it from the locking configuration. But I think "write
> >>> skew disabled" should be another locking mode, perhaps called
> >>> LAST_WRITE_WINS.
> >>>
> >>>>
> >>>>> - SingletonStore - pushStateWhenCoordinator implicit by
> pushStateTimeout
> >>>>> -> flushTimeout
> >>>>> - StateTransfer.fetchInMemoryState -> renamed to enabled
> >>>
> >>> +1
> >>>
> >>>>> - StoreAsBinary - remove ?enabled? and reply on storeKey/storeBinary
> +
> >>>>> remove deprecation
> >>>>> - remove deprecations from TransactionConfiguration and remove
> >>>>> use1PcForAutCommitTx
> >>>
> >>> +1
> >>>
> >>>>> - VersioningConfiguration.enabled should be computed based on the
> scheme
> >>>>> and removed
> >>>
> >>> +1
> >>>
> >>>>> - Version - remove the version fields and populate them through a
> mvn script
> >>>>> - SerializationConfigurationBuilder - consider removing the version
> field
> >>>
> >>> +1 to remove it, the javadoc there suggests we support
> >>> interoperability between different Infinispan versions and that's
> >>> still too onerous for us at this point.
> >>>
> >>>>> - ShutdownConfiguration - to be removed, confirm with an email
> >>>>> - TransportConfiguration.distributedSyncTimeout -> global RPC timeout
> >>>
> >>> +1
> >>>
> >>>>> - strictPeerToPeer should go as it is deprecated
> >>>
> >>> +1
> >>>
> >>>>>
> >>>>
> >>>> another suggestion:
> >>>>
> >>>> - Transaction, remove the transaction_protocol and add TOTAL as an
> >>>> option for locking_mode
> >>>>
> >>>> *or*
> >>>>
> >>>> - Transaction, remove the transaction_protocol
> >>>> - Locking, add locking mode with LOCK and TOTAL_ORDER options (since
> >>>> I'll probably implement total order based non transactional caches)
> >>>
> >>> I don't feel like TOTAL belongs to the locking element. Since total
> >>> order is only relevant in clustered caches, how about making it an
> >>> alternative clustering mode?
> >>>
> >>> <clustering mode="SYNC|ASYNC|TOTAL"/>
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> [1] https://issues.jboss.org/browse/ISPN-2939
> >>>>> [2] https://issues.jboss.org/browse/ISPN-3927
> >>>>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > _______________________________________________
> > 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/20150523/7d9bf092/attachment-0001.html 

From ttarrant at redhat.com  Mon May 25 10:41:16 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 25 May 2015 16:41:16 +0200
Subject: [infinispan-dev] Weekly IRC meeting minutes 2015-05-25
Message-ID: <5563348C.4050807@redhat.com>

Since JBott is still acting up, here are the logs:

16:03:26 <ttarrant>	#startmeeting
16:03:27 <jbott>	ttarrant: Error: Can't start another meeting, one is in 
progress.
16:03:35 <ttarrant>	hehe
16:03:38 <vblagoje>	:-)
16:03:43 <ttarrant>	jbott, reboot
16:03:43 <jbott>	ttarrant: Error: "reboot" is not a valid command.
16:03:47 <ttarrant>	ok
16:03:53 <ttarrant>	#topic ttarrant
16:04:06 <pruivo>	ttarrant: lool
16:04:20 <pruivo>	ttarrant: try sudo reboot
16:04:21 <galderz>	yup ttarrant
16:04:26 <ttarrant>	last week I took over ISPN-5345 from wburns to 
finish some configuration aspects
16:04:27 <jbossbot>	jira [ISPN-5345] Allow eviction based on 
approximation of size compared to element count [Resolved (Done) 
Enhancement, Major, William Burns] https://issues.jboss.org/browse/ISPN-5345
16:04:45 <ttarrant>	after a few iterations about how it should look, 
dberindei and I came to an agreement :)
16:05:43 <ttarrant>	next up I finally implemented ISPN-2939
16:05:44 <jbossbot>	jira [ISPN-2939] Remove option for async Marshalling 
[Resolved (Done) Task, Minor, Tristan Tarrant] 
https://issues.jboss.org/browse/ISPN-2939
16:06:29 <ttarrant>	I also handled the new codename poll
16:06:53 <ttarrant>	and made sure we only have to change the codename in 
one place with ISPN-5503
16:06:54 <jbossbot>	jira [ISPN-5503] Codename should be injected in 
Version.java [Resolved (Done) Bug, Minor, Tristan Tarrant] 
https://issues.jboss.org/browse/ISPN-5503
16:06:57 <vblagoje>	What was the vount count ttarrant?
16:07:01 <--	emmanuel has quit (Quit: ZNC - http://znc.in)
16:07:08 <ttarrant>	vblagoje, there were about 100 votes
16:07:21 <vblagoje>	Not bad?
16:07:57 <ttarrant>	I also told our design team to give us a few colour 
variations of the chosen logo for Infinispan 8
16:08:03 <ttarrant>	it seems everybody liked v1
16:08:09 <ttarrant> 
http://design.jboss.org/infinispan/infinispan8/logo/images/infinispan8_logo_r1v1.png
16:08:47 <ttarrant>	I can't remember if I mentioned it last week, but I 
also did 
https://github.com/infinispan/infinispan-cachestore-archetype/pull/1
16:08:47 <jbossbot>	git pull req [infinispan-cachestore-archetype] 
(open) tristantarrant Flesh out the archetypes with addtional 
documentation and tips 
https://github.com/infinispan/infinispan-cachestore-archetype/pull/1
16:08:51 <ttarrant>	please review it
16:09:06 <ttarrant>	it would be nice to do a "how to write a cachestore 
tutorial"
16:09:07 <vblagoje>	ok will do so
16:09:44 <ttarrant>	ISPN-4919 was put on hold after I spoke a bit with 
pferraro so that the management model is sane
16:09:45 <jbossbot>	jira [ISPN-4919] Configuration templates [Pull 
Request Sent (Unresolved) Feature Request, Major, Tristan Tarrant] 
https://issues.jboss.org/browse/ISPN-4919
16:09:52 <ttarrant>	should be able to finish this week
16:10:43 <ttarrant>	I'm also nearly done with the WildFly Core rebase
16:11:30 <ttarrant>	I was hoping that the "feature pack" aspect of WF 
would help us in making a leaner distro, but it isn't
16:11:58 <ttarrant>	I would like to release 8.0.0.Alpha1 today. I'll 
handle the release
16:12:06 <galderz>	ttarrant: i had a look at the archetype PR
16:12:32 <ttarrant>	I guess 
https://github.com/infinispan/infinispan/pull/3501 needs to go in before 
we release though
16:12:32 <jbossbot>	git pull req [infinispan] (open) galderz ISPN-5477 
When entry comes from L1, mark it as remotely fetched 
https://github.com/infinispan/infinispan/pull/3501
16:12:32 <jbossbot>	jira [ISPN-5477] Compatibility with L1 can lead to 
wrong return type [Reopened (Unresolved) Bug, Major, Galder Zamarre?o] 
https://issues.jboss.org/browse/ISPN-5477
16:12:59 <ttarrant>	next week I'll be on PTO on Monday and public 
holiday on tuesday
16:13:05 <ttarrant>	anistor, ?
16:13:11 <anistor>	ttarrant: y
16:13:12 <ttarrant>	#topic anistor
16:13:20 -->	emmanuel_off 
(~epbernard at APuteaux-653-1-58-20.w86-195.abo.wanadoo.fr) has joined 
#infinispan
16:13:26 <galderz>	ttarrant: yeah..., not sure it's the cleanest 
solution though, maybe will has other ideas but not sure he's online now?
16:13:28 ---	emmanuel_off is now known as emmanuel
16:13:29 <--	emmanuel has quit (Changing host)
16:13:29 -->	emmanuel (~epbernard at redhat/jboss/epbernard) has joined 
#infinispan
16:13:35 <anistor>	last week I worked on ISPN-5393
16:13:35 <jbossbot>	jira [ISPN-5393] Support mixed indexed and 
non-indexed fields in DSL based queries [Open (Unresolved) Enhancement, 
Major, Adrian Nistor] https://issues.jboss.org/browse/ISPN-5393
16:14:01 <anistor>	this involves a lot of changes
16:15:37 <anistor>	I've extracted the minimum into a separate pr which 
solves just the issue of seamlessly switching between full indexed  and 
full non-indexed query: ISPN-5477
16:15:37 <jbossbot>	jira [ISPN-5477] Compatibility with L1 can lead to 
wrong return type [Reopened (Unresolved) Bug, Major, Galder Zamarre?o] 
https://issues.jboss.org/browse/ISPN-5477
16:16:26 <anistor>	and I hope once this is integrated in master I'll 
backport to 7.2.x too. it's a really useful non-api changing feature
16:16:32 <anistor>	from the usability POV
16:17:02 <anistor>	last week I also worked an an issue with the module 
structure: ISPN-5501
16:17:02 <jbossbot>	jira [ISPN-5501] Camel throwing 
java.lang.LinkageError for Remote Query when running in EAP [Resolved 
(Done) Bug, Major, Adrian Nistor] https://issues.jboss.org/browse/ISPN-5501
16:17:16 <anistor>	and ISPN-5463
16:17:17 <jbossbot>	jira [ISPN-5463] ClassCastException: 
org.infinispan.query.remote.indexing.ProtobufValueWrapper cannot be cast 
to [B [Open (Unresolved) Bug, Major, Adrian Nistor] 
https://issues.jboss.org/browse/ISPN-5463
16:17:57 <anistor>	this week I need to finish ISPN-5393 and then start 
implementing aggregations
16:17:57 <jbossbot>	jira [ISPN-5393] Support mixed indexed and 
non-indexed fields in DSL based queries [Open (Unresolved) Enhancement, 
Major, Adrian Nistor] https://issues.jboss.org/browse/ISPN-5393
16:18:26 <anistor>	aggregations need this mixed mode query too
16:18:32 <anistor>	that's it from me
16:18:36 <anistor>	dberindei: next?
16:18:41 <dberindei>	sure anistor
16:18:45 <dberindei>	#topic dberindei
16:19:23 <dberindei>	last week I worked a bit on the test suite: 
ISPN-5480, ISPN-5492, ISPN-5472
16:19:23 <jbossbot>	jira [ISPN-5480] Speed up xsite tests [Resolved 
(Done) Task, Major, Dan Berindei] https://issues.jboss.org/browse/ISPN-5480
16:19:24 <jbossbot>	jira [ISPN-5492] 
DelayedAvailabilityUpdateTest.testDelayedAvailabilityUpdate2 random 
failures [Resolved (Done) Bug, Blocker, Dan Berindei] 
https://issues.jboss.org/browse/ISPN-5492
16:19:24 <jbossbot>	jira [ISPN-5472] Surefire crashes during LevelDB 
test suite [Resolved (Done) Bug, Blocker, Dan Berindei] 
https://issues.jboss.org/browse/ISPN-5472
16:19:32 <dberindei>	also ISPN-5494
16:19:32 <jbossbot>	jira [ISPN-5494] Node replies with 
NullPointerException during shutdown [Resolved (Done) Bug, Blocker, Dan 
Berindei] https://issues.jboss.org/browse/ISPN-5494
16:20:10 <dberindei>	I started rather timidly with the 8.0 stuff, I 
implemented ISPN-2154 and now I'm working on ISPN-5484
16:20:10 <jbossbot>	jira [ISPN-2154] Use JGroups' anycast when sending 
messages to multiple target [Pull Request Sent (Unresolved) Task, Minor, 
Dan Berindei] https://issues.jboss.org/browse/ISPN-2154
16:20:11 <jbossbot>	jira [ISPN-5484] RpcManager.invokeRemotelyInFuture 
should not use a transport thread [Pull Request Sent (Unresolved) 
Enhancement, Major, Dan Berindei] https://issues.jboss.org/browse/ISPN-5484
16:20:31 <dberindei>	thanks for removing the async marshalling config 
ttarrant!
16:20:38 *	ttarrant bows
16:20:51 <ttarrant>	dberindei, less is more
16:21:02 <dberindei>	for the rest of the week, I plan to finish 5484 and 
start working on the refactoring of write operations
16:21:12 <dberindei>	indeed ttarrant
16:21:20 <dberindei>	that's all from me, galderz next?
16:21:47 <galderz>	sure
16:22:16 <galderz>	last week I worked on ISPN-5477, whose fixes did not 
fully work and today I sent another PR
16:22:16 <jbossbot>	jira [ISPN-5477] Compatibility with L1 can lead to 
wrong return type [Reopened (Unresolved) Bug, Major, Galder Zamarre?o] 
https://issues.jboss.org/browse/ISPN-5477
16:22:45 <galderz>	i also fixed ISPN-5490 and ISPN-5488 and investigated 
some product issues
16:22:45 <jbossbot>	jira [ISPN-5490] Cache.clear() does not clear the 
cache store with async store [Resolved (Done) Bug, Major, Galder 
Zamarre?o] https://issues.jboss.org/browse/ISPN-5490
16:22:46 <jbossbot>	jira [ISPN-5488] 
DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges 
random failures [Resolved (Done) Bug, Blocker, Galder Zamarre?o] 
https://issues.jboss.org/browse/ISPN-5488
16:23:35 <galderz>	on the Java 8 API prototype front, the prototype is 
almost complete. I'm in the process of adding very detailed javadocs 
which hopefully will make it clear the design and how to use it
16:24:13 <galderz>	it's fairly different to the original design sent 
around. I hope to be ready by the end of the week and when that's ready 
I'll send an email around
16:24:54 <galderz>	that's about it for me
16:25:27 <galderz>	isavin: next?
16:25:33 <isavin>	isavin, sure
16:25:36 <isavin>	#topic isavin
16:25:39 <galderz>	gustavo's not around, i think it's bank holiday in UK
16:26:16 <isavin>	last week I did some maintenance work related to 
CI/release
16:26:40 <isavin>	and worked on HRCPP-191, there's a problem on windows
16:26:41 <jbossbot>	jira [HRCPP-191] Cpp client test applications should 
link to the static library [Pull Request Sent (Unresolved) Enhancement, 
Major, Alan Field] https://issues.jboss.org/browse/HRCPP-191
16:27:18 <isavin>	and the static library segfaults
16:28:19 <isavin>	I have a solution but need to clean-up a bit the way 
parameters are passed to the compiler as they need to be different on 
debug/release/relwithdebinfo/etc configurations
16:28:31 <isavin>	one I'm done with this I'll start on ISPN-5433
16:28:32 <jbossbot>	jira [ISPN-5433] JSR-107 Support for standard 
annotations in client-server mode [New (Unresolved) Feature Request, 
Major, Unassigned] https://issues.jboss.org/browse/ISPN-5433
16:28:44 <isavin>	that's all from me, pruivo next?
16:28:55 <pruivo>	yes isavin :)
16:29:02 <pruivo>	#topic pruivo
16:29:06 <pruivo>	hi guys
16:29:21 <pruivo>	last week, I was on PTO mon and tue
16:30:10 <pruivo>	I've updated the PR for ISPN-5046 based on Dan's comments
16:30:11 <jbossbot>	jira [ISPN-5046] PartitionHandling: split during 
commit can leave the cache inconsistent after merge [Pull Request Sent 
(Unresolved) Bug, Critical, Pedro Ruivo] 
https://issues.jboss.org/browse/ISPN-5046
16:30:41 <pruivo>	and I start re-working on the locking for remote 
commands: ISPN-2849
16:30:41 <jbossbot>	jira [ISPN-2849] Don't keep threads blocked when 
waiting for locks to be released [Coding In Progress (Unresolved) 
Feature Request, Major, Pedro Ruivo] 
https://issues.jboss.org/browse/ISPN-2849
16:31:10 <pruivo>	I have some ideas how to improve my initial approach 
and since it will hit 8.0, I can play a little better with the 
LockManager API :D
16:31:38 <pruivo>	I'm starting testing it to see if it works (however, I 
have a problem with the deadlock detector...)
16:31:51 <pruivo>	talking about the future, this week I'll continue work 
on that
16:32:11 <pruivo>	and possible other high priority stuff that pops up in 
my queue
16:32:23 <pruivo>	and that's it
16:32:26 <pruivo>	vblagoje: next?
16:32:29 <vblagoje>	sure
16:32:39 <vblagoje>	#topic vblagoje
16:32:59 <vblagoje>	Last week I got to invoke cache creation from 
javascript code :-)
16:33:25 <vblagoje>	So I played around with that and figured out all the 
nuances of REST DMR invocation
16:33:56 <vblagoje>	Then I started to write the API for creation of 
cache and all the child nodes of cache (locking, eviction laoders?etc)
16:34:20 <vblagoje>	I am half way through that part and I expect to 
finish it by Wenedesday when I want to issue PR
16:34:56 <vblagoje>	The plab is to have this API ready for June 2 when 
UI/X should be finalized. Then we move onto wiring UI with this 
javascript API
16:35:09 <vblagoje>	That?s about it
16:35:36 <vblagoje>	since wburns is on PTO, I think that?s about it ttarrant
16:36:15 <ttarrant>	vblagoje, thanks
16:36:19 <ttarrant>	and thanks to everybody else
16:36:31 *	ttarrant tiptoes to catch jbott by surprise
16:36:34 <ttarrant>	#endmeeting
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From ttarrant at redhat.com  Mon May 25 15:31:24 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 25 May 2015 21:31:24 +0200
Subject: [infinispan-dev] Infinispan 8.0.0.Alpha1
Message-ID: <5563788C.6070008@redhat.com>

Dear all,

Infinispan 8.0.0.Alpha1 is now available. Please check our blog [1] for 
release notes, download links and additional information.


Tristan

[1] http://blog.infinispan.org/
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From mudokonman at gmail.com  Tue May 26 08:42:24 2015
From: mudokonman at gmail.com (William Burns)
Date: Tue, 26 May 2015 12:42:24 +0000
Subject: [infinispan-dev] Weekly IRC meeting minutes 2015-05-25
In-Reply-To: <5563348C.4050807@redhat.com>
References: <5563348C.4050807@redhat.com>
Message-ID: <CA+YCuUOGeR=TYi+1kMfMLBV15iphYc4+8jWpFQmy+2COYQshjQ@mail.gmail.com>

Since I was on holiday on Monday, just sending my update now.

Last week:

I worked on and got in https://issues.jboss.org/browse/ISPN-5345 which
Tristan added some configuration changes for, thanks Tristan.
Also got in https://github.com/infinispan/infinispan/pull/3475

I started working on the initial changes for
https://issues.jboss.org/browse/ISPN-5293.  I had some time to think about
this some more during this time and actually have a nice local
implementation done.

This week:

I will write up a blog post for ISPN-5345.  Also I wanted to add another
test(s) for it to confirm some behavior.

I will also be working on a design document for ISPN-5293 for the
distributed version so others can comment on it.





On Mon, May 25, 2015 at 10:41 AM Tristan Tarrant <ttarrant at redhat.com>
wrote:

> Since JBott is still acting up, here are the logs:
>
> 16:03:26 <ttarrant>     #startmeeting
> 16:03:27 <jbott>        ttarrant: Error: Can't start another meeting, one
> is in
> progress.
> 16:03:35 <ttarrant>     hehe
> 16:03:38 <vblagoje>     :-)
> 16:03:43 <ttarrant>     jbott, reboot
> 16:03:43 <jbott>        ttarrant: Error: "reboot" is not a valid command.
> 16:03:47 <ttarrant>     ok
> 16:03:53 <ttarrant>     #topic ttarrant
> 16:04:06 <pruivo>       ttarrant: lool
> 16:04:20 <pruivo>       ttarrant: try sudo reboot
> 16:04:21 <galderz>      yup ttarrant
> 16:04:26 <ttarrant>     last week I took over ISPN-5345 from wburns to
> finish some configuration aspects
> 16:04:27 <jbossbot>     jira [ISPN-5345] Allow eviction based on
> approximation of size compared to element count [Resolved (Done)
> Enhancement, Major, William Burns]
> https://issues.jboss.org/browse/ISPN-5345
> 16:04:45 <ttarrant>     after a few iterations about how it should look,
> dberindei and I came to an agreement :)
> 16:05:43 <ttarrant>     next up I finally implemented ISPN-2939
> 16:05:44 <jbossbot>     jira [ISPN-2939] Remove option for async
> Marshalling
> [Resolved (Done) Task, Minor, Tristan Tarrant]
> https://issues.jboss.org/browse/ISPN-2939
> 16:06:29 <ttarrant>     I also handled the new codename poll
> 16:06:53 <ttarrant>     and made sure we only have to change the codename
> in
> one place with ISPN-5503
> 16:06:54 <jbossbot>     jira [ISPN-5503] Codename should be injected in
> Version.java [Resolved (Done) Bug, Minor, Tristan Tarrant]
> https://issues.jboss.org/browse/ISPN-5503
> 16:06:57 <vblagoje>     What was the vount count ttarrant?
> 16:07:01 <--    emmanuel has quit (Quit: ZNC - http://znc.in)
> 16:07:08 <ttarrant>     vblagoje, there were about 100 votes
> 16:07:21 <vblagoje>     Not bad?
> 16:07:57 <ttarrant>     I also told our design team to give us a few colour
> variations of the chosen logo for Infinispan 8
> 16:08:03 <ttarrant>     it seems everybody liked v1
> 16:08:09 <ttarrant>
>
> http://design.jboss.org/infinispan/infinispan8/logo/images/infinispan8_logo_r1v1.png
> 16:08:47 <ttarrant>     I can't remember if I mentioned it last week, but I
> also did
> https://github.com/infinispan/infinispan-cachestore-archetype/pull/1
> 16:08:47 <jbossbot>     git pull req [infinispan-cachestore-archetype]
> (open) tristantarrant Flesh out the archetypes with addtional
> documentation and tips
> https://github.com/infinispan/infinispan-cachestore-archetype/pull/1
> 16:08:51 <ttarrant>     please review it
> 16:09:06 <ttarrant>     it would be nice to do a "how to write a cachestore
> tutorial"
> 16:09:07 <vblagoje>     ok will do so
> 16:09:44 <ttarrant>     ISPN-4919 was put on hold after I spoke a bit with
> pferraro so that the management model is sane
> 16:09:45 <jbossbot>     jira [ISPN-4919] Configuration templates [Pull
> Request Sent (Unresolved) Feature Request, Major, Tristan Tarrant]
> https://issues.jboss.org/browse/ISPN-4919
> 16:09:52 <ttarrant>     should be able to finish this week
> 16:10:43 <ttarrant>     I'm also nearly done with the WildFly Core rebase
> 16:11:30 <ttarrant>     I was hoping that the "feature pack" aspect of WF
> would help us in making a leaner distro, but it isn't
> 16:11:58 <ttarrant>     I would like to release 8.0.0.Alpha1 today. I'll
> handle the release
> 16:12:06 <galderz>      ttarrant: i had a look at the archetype PR
> 16:12:32 <ttarrant>     I guess
> https://github.com/infinispan/infinispan/pull/3501 needs to go in before
> we release though
> 16:12:32 <jbossbot>     git pull req [infinispan] (open) galderz ISPN-5477
> When entry comes from L1, mark it as remotely fetched
> https://github.com/infinispan/infinispan/pull/3501
> 16:12:32 <jbossbot>     jira [ISPN-5477] Compatibility with L1 can lead to
> wrong return type [Reopened (Unresolved) Bug, Major, Galder Zamarre?o]
> https://issues.jboss.org/browse/ISPN-5477
> 16:12:59 <ttarrant>     next week I'll be on PTO on Monday and public
> holiday on tuesday
> 16:13:05 <ttarrant>     anistor, ?
> 16:13:11 <anistor>      ttarrant: y
> 16:13:12 <ttarrant>     #topic anistor
> 16:13:20 -->    emmanuel_off
> (~epbernard at APuteaux-653-1-58-20.w86-195.abo.wanadoo.fr) has joined
> #infinispan
> 16:13:26 <galderz>      ttarrant: yeah..., not sure it's the cleanest
> solution though, maybe will has other ideas but not sure he's online now?
> 16:13:28 ---    emmanuel_off is now known as emmanuel
> 16:13:29 <--    emmanuel has quit (Changing host)
> 16:13:29 -->    emmanuel (~epbernard at redhat/jboss/epbernard) has joined
> #infinispan
> 16:13:35 <anistor>      last week I worked on ISPN-5393
> 16:13:35 <jbossbot>     jira [ISPN-5393] Support mixed indexed and
> non-indexed fields in DSL based queries [Open (Unresolved) Enhancement,
> Major, Adrian Nistor] https://issues.jboss.org/browse/ISPN-5393
> 16:14:01 <anistor>      this involves a lot of changes
> 16:15:37 <anistor>      I've extracted the minimum into a separate pr which
> solves just the issue of seamlessly switching between full indexed  and
> full non-indexed query: ISPN-5477
> 16:15:37 <jbossbot>     jira [ISPN-5477] Compatibility with L1 can lead to
> wrong return type [Reopened (Unresolved) Bug, Major, Galder Zamarre?o]
> https://issues.jboss.org/browse/ISPN-5477
> 16:16:26 <anistor>      and I hope once this is integrated in master I'll
> backport to 7.2.x too. it's a really useful non-api changing feature
> 16:16:32 <anistor>      from the usability POV
> 16:17:02 <anistor>      last week I also worked an an issue with the module
> structure: ISPN-5501
> 16:17:02 <jbossbot>     jira [ISPN-5501] Camel throwing
> java.lang.LinkageError for Remote Query when running in EAP [Resolved
> (Done) Bug, Major, Adrian Nistor]
> https://issues.jboss.org/browse/ISPN-5501
> 16:17:16 <anistor>      and ISPN-5463
> 16:17:17 <jbossbot>     jira [ISPN-5463] ClassCastException:
> org.infinispan.query.remote.indexing.ProtobufValueWrapper cannot be cast
> to [B [Open (Unresolved) Bug, Major, Adrian Nistor]
> https://issues.jboss.org/browse/ISPN-5463
> 16:17:57 <anistor>      this week I need to finish ISPN-5393 and then start
> implementing aggregations
> 16:17:57 <jbossbot>     jira [ISPN-5393] Support mixed indexed and
> non-indexed fields in DSL based queries [Open (Unresolved) Enhancement,
> Major, Adrian Nistor] https://issues.jboss.org/browse/ISPN-5393
> 16:18:26 <anistor>      aggregations need this mixed mode query too
> 16:18:32 <anistor>      that's it from me
> 16:18:36 <anistor>      dberindei: next?
> 16:18:41 <dberindei>    sure anistor
> 16:18:45 <dberindei>    #topic dberindei
> 16:19:23 <dberindei>    last week I worked a bit on the test suite:
> ISPN-5480, ISPN-5492, ISPN-5472
> 16:19:23 <jbossbot>     jira [ISPN-5480] Speed up xsite tests [Resolved
> (Done) Task, Major, Dan Berindei]
> https://issues.jboss.org/browse/ISPN-5480
> 16:19:24 <jbossbot>     jira [ISPN-5492]
> DelayedAvailabilityUpdateTest.testDelayedAvailabilityUpdate2 random
> failures [Resolved (Done) Bug, Blocker, Dan Berindei]
> https://issues.jboss.org/browse/ISPN-5492
> 16:19:24 <jbossbot>     jira [ISPN-5472] Surefire crashes during LevelDB
> test suite [Resolved (Done) Bug, Blocker, Dan Berindei]
> https://issues.jboss.org/browse/ISPN-5472
> 16:19:32 <dberindei>    also ISPN-5494
> 16:19:32 <jbossbot>     jira [ISPN-5494] Node replies with
> NullPointerException during shutdown [Resolved (Done) Bug, Blocker, Dan
> Berindei] https://issues.jboss.org/browse/ISPN-5494
> 16:20:10 <dberindei>    I started rather timidly with the 8.0 stuff, I
> implemented ISPN-2154 and now I'm working on ISPN-5484
> 16:20:10 <jbossbot>     jira [ISPN-2154] Use JGroups' anycast when sending
> messages to multiple target [Pull Request Sent (Unresolved) Task, Minor,
> Dan Berindei] https://issues.jboss.org/browse/ISPN-2154
> 16:20:11 <jbossbot>     jira [ISPN-5484] RpcManager.invokeRemotelyInFuture
> should not use a transport thread [Pull Request Sent (Unresolved)
> Enhancement, Major, Dan Berindei]
> https://issues.jboss.org/browse/ISPN-5484
> 16:20:31 <dberindei>    thanks for removing the async marshalling config
> ttarrant!
> 16:20:38 *      ttarrant bows
> 16:20:51 <ttarrant>     dberindei, less is more
> 16:21:02 <dberindei>    for the rest of the week, I plan to finish 5484 and
> start working on the refactoring of write operations
> 16:21:12 <dberindei>    indeed ttarrant
> 16:21:20 <dberindei>    that's all from me, galderz next?
> 16:21:47 <galderz>      sure
> 16:22:16 <galderz>      last week I worked on ISPN-5477, whose fixes did
> not
> fully work and today I sent another PR
> 16:22:16 <jbossbot>     jira [ISPN-5477] Compatibility with L1 can lead to
> wrong return type [Reopened (Unresolved) Bug, Major, Galder Zamarre?o]
> https://issues.jboss.org/browse/ISPN-5477
> 16:22:45 <galderz>      i also fixed ISPN-5490 and ISPN-5488 and
> investigated
> some product issues
> 16:22:45 <jbossbot>     jira [ISPN-5490] Cache.clear() does not clear the
> cache store with async store [Resolved (Done) Bug, Major, Galder
> Zamarre?o] https://issues.jboss.org/browse/ISPN-5490
> 16:22:46 <jbossbot>     jira [ISPN-5488]
> DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges
> random failures [Resolved (Done) Bug, Blocker, Galder Zamarre?o]
> https://issues.jboss.org/browse/ISPN-5488
> 16:23:35 <galderz>      on the Java 8 API prototype front, the prototype is
> almost complete. I'm in the process of adding very detailed javadocs
> which hopefully will make it clear the design and how to use it
> 16:24:13 <galderz>      it's fairly different to the original design sent
> around. I hope to be ready by the end of the week and when that's ready
> I'll send an email around
> 16:24:54 <galderz>      that's about it for me
> 16:25:27 <galderz>      isavin: next?
> 16:25:33 <isavin>       isavin, sure
> 16:25:36 <isavin>       #topic isavin
> 16:25:39 <galderz>      gustavo's not around, i think it's bank holiday in
> UK
> 16:26:16 <isavin>       last week I did some maintenance work related to
> CI/release
> 16:26:40 <isavin>       and worked on HRCPP-191, there's a problem on
> windows
> 16:26:41 <jbossbot>     jira [HRCPP-191] Cpp client test applications
> should
> link to the static library [Pull Request Sent (Unresolved) Enhancement,
> Major, Alan Field] https://issues.jboss.org/browse/HRCPP-191
> 16:27:18 <isavin>       and the static library segfaults
> 16:28:19 <isavin>       I have a solution but need to clean-up a bit the
> way
> parameters are passed to the compiler as they need to be different on
> debug/release/relwithdebinfo/etc configurations
> 16:28:31 <isavin>       one I'm done with this I'll start on ISPN-5433
> 16:28:32 <jbossbot>     jira [ISPN-5433] JSR-107 Support for standard
> annotations in client-server mode [New (Unresolved) Feature Request,
> Major, Unassigned] https://issues.jboss.org/browse/ISPN-5433
> 16:28:44 <isavin>       that's all from me, pruivo next?
> 16:28:55 <pruivo>       yes isavin :)
> 16:29:02 <pruivo>       #topic pruivo
> 16:29:06 <pruivo>       hi guys
> 16:29:21 <pruivo>       last week, I was on PTO mon and tue
> 16:30:10 <pruivo>       I've updated the PR for ISPN-5046 based on Dan's
> comments
> 16:30:11 <jbossbot>     jira [ISPN-5046] PartitionHandling: split during
> commit can leave the cache inconsistent after merge [Pull Request Sent
> (Unresolved) Bug, Critical, Pedro Ruivo]
> https://issues.jboss.org/browse/ISPN-5046
> 16:30:41 <pruivo>       and I start re-working on the locking for remote
> commands: ISPN-2849
> 16:30:41 <jbossbot>     jira [ISPN-2849] Don't keep threads blocked when
> waiting for locks to be released [Coding In Progress (Unresolved)
> Feature Request, Major, Pedro Ruivo]
> https://issues.jboss.org/browse/ISPN-2849
> 16:31:10 <pruivo>       I have some ideas how to improve my initial
> approach
> and since it will hit 8.0, I can play a little better with the
> LockManager API :D
> 16:31:38 <pruivo>       I'm starting testing it to see if it works
> (however, I
> have a problem with the deadlock detector...)
> 16:31:51 <pruivo>       talking about the future, this week I'll continue
> work
> on that
> 16:32:11 <pruivo>       and possible other high priority stuff that pops
> up in
> my queue
> 16:32:23 <pruivo>       and that's it
> 16:32:26 <pruivo>       vblagoje: next?
> 16:32:29 <vblagoje>     sure
> 16:32:39 <vblagoje>     #topic vblagoje
> 16:32:59 <vblagoje>     Last week I got to invoke cache creation from
> javascript code :-)
> 16:33:25 <vblagoje>     So I played around with that and figured out all
> the
> nuances of REST DMR invocation
> 16:33:56 <vblagoje>     Then I started to write the API for creation of
> cache and all the child nodes of cache (locking, eviction laoders?etc)
> 16:34:20 <vblagoje>     I am half way through that part and I expect to
> finish it by Wenedesday when I want to issue PR
> 16:34:56 <vblagoje>     The plab is to have this API ready for June 2 when
> UI/X should be finalized. Then we move onto wiring UI with this
> javascript API
> 16:35:09 <vblagoje>     That?s about it
> 16:35:36 <vblagoje>     since wburns is on PTO, I think that?s about it
> ttarrant
> 16:36:15 <ttarrant>     vblagoje, thanks
> 16:36:19 <ttarrant>     and thanks to everybody else
> 16:36:31 *      ttarrant tiptoes to catch jbott by surprise
> 16:36:34 <ttarrant>     #endmeeting
> --
> 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/20150526/3b94a02b/attachment-0001.html 

From mudokonman at gmail.com  Wed May 27 14:52:42 2015
From: mudokonman at gmail.com (William Burns)
Date: Wed, 27 May 2015 18:52:42 +0000
Subject: [infinispan-dev] Distributed Streams
Message-ID: <CA+YCuUNqdC=S8kvY7LPW47D12pGYzwXawQeBpjMhLhzDUcbOOA@mail.gmail.com>

Hello everyone,

I wanted to let you know I wrote up a design documenting the successor to
EntryRetriever, Distributed Streams [1] !

Any comments or feedback would be much appreciated.

I especially would like targeted feedback regarding:

1. The operators forEach and peek may want to be ran locally.  Should we
have an overridden method so users can pick which they want?  Personally I
feel that peek is too specific to matter and forEach can always be done by
the caller locally if desired.
2. The intermediate operators limit and skip do not seem worth implementing
unless we have sorting support. (Sorting support will come later).  I am
thinking to not support these until sorting is added.

Thanks,

 - Will

[1] https://github.com/infinispan/infinispan/wiki/Distributed-Stream-Support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150527/0c6b1533/attachment.html 

From vblagoje at redhat.com  Wed May 27 15:19:11 2015
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Wed, 27 May 2015 15:19:11 -0400
Subject: [infinispan-dev] Infinispan 7.2.2.Final is out
Message-ID: <556618AF.4040909@redhat.com>

Hello everyone,

We have released 7.2.2.Final today. This release does not include any 
new features, but it has resolutions for the minor bugs we have found 
since we released 7.2.1.Final.

Please check outhttp://blog.infinispan.org  for release notes, download links and additional information.

Regards,
Vladimir



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