From ttarrant at redhat.com  Mon Oct  2 14:11:22 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 2 Oct 2017 20:11:22 +0200
Subject: [infinispan-dev] Infinispan Weekly IRC Meeting Logs 2017-10-02
Message-ID: <44e7aef2-4998-8397-c7b2-a642664211f8@redhat.com>

Hi all,

here are the logs for this week's meeting:

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

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

From vblagoje at redhat.com  Fri Oct  6 04:35:47 2017
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Fri, 6 Oct 2017 04:35:47 -0400
Subject: [infinispan-dev] Infinispan 9.2.0Alpha1 has been released
Message-ID: <fbcebf3e-8bee-f016-bdca-715c34a59532@redhat.com>

Hey everyone,

Our first release on Infinispan 9.2 branch is out. Read more about it at 
http://blog.infinispan.org/2017/10/infinispan-920alpha1-released.html

Regards,

Vladimir


From tsegismont at gmail.com  Mon Oct  9 09:04:30 2017
From: tsegismont at gmail.com (Thomas SEGISMONT)
Date: Mon, 9 Oct 2017 15:04:30 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
Message-ID: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>

Hi,

I've created a branch in vertx-infinispan to start incorporating the new
features in 9.2.

https://github.com/vert-x3/vertx-infinispan/tree/ispn92

Here are a couple of comments/concerns on MultimapCache:
1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
MultimapCacheManager; it would be nice to have type arguments instead, to
avoid unchecked assignment warnings
2/ MultimapCache does not accept entry listeners. We use them to build a
near cache to increase the speed of sending

1/ is easy, but do you think 2/ could be added in 9.2?

Thank you,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171009/e99d03f5/attachment-0001.html 

From rvansa at redhat.com  Mon Oct  9 12:30:51 2017
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 9 Oct 2017 18:30:51 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
Message-ID: <e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>

On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
> Hi,
>
> I've created a branch in vertx-infinispan to start incorporating the 
> new features in 9.2.
>
> https://github.com/vert-x3/vertx-infinispan/tree/ispn92 
> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>
> Here are a couple of comments/concerns on MultimapCache:
> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw 
> MultimapCacheManager; it would be nice to have type arguments instead, 
> to avoid unchecked assignment warnings
> 2/ MultimapCache does not accept entry listeners. We use them to build 
> a near cache to increase the speed of sending

Do you need clustered listeners or only those on owners? Btw., you can 
register a listener on the underlying cache, but I agree that an 
interface that will adapt it correctly (e.g. mapping @EntryModified on 
multi-value to @EntryCreated on the new value) would appear less crude.

R.

>
> 1/ is easy, but do you think 2/ could be added in 9.2?
>
> Thank you,
> Thomas
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


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


From emmanuel at hibernate.org  Mon Oct  9 13:21:59 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 9 Oct 2017 19:21:59 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
Message-ID: <E9B7C8F5-A973-4816-809C-C6EC7F1DDAC7@hibernate.org>

Stupid question. Hot Rod does not have near cache invalidation already ? Does not suit your needs or not implemented for multimapcache?

> On 9 Oct 2017, at 18:30, Radim Vansa <rvansa at redhat.com> wrote:
> 
>> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
>> Hi,
>> 
>> I've created a branch in vertx-infinispan to start incorporating the 
>> new features in 9.2.
>> 
>> https://github.com/vert-x3/vertx-infinispan/tree/ispn92 
>> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>> 
>> Here are a couple of comments/concerns on MultimapCache:
>> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw 
>> MultimapCacheManager; it would be nice to have type arguments instead, 
>> to avoid unchecked assignment warnings
>> 2/ MultimapCache does not accept entry listeners. We use them to build 
>> a near cache to increase the speed of sending
> 
> Do you need clustered listeners or only those on owners? Btw., you can 
> register a listener on the underlying cache, but I agree that an 
> interface that will adapt it correctly (e.g. mapping @EntryModified on 
> multi-value to @EntryCreated on the new value) would appear less crude.
> 
> R.
> 
>> 
>> 1/ is easy, but do you think 2/ could be added in 9.2?
>> 
>> Thank you,
>> Thomas
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From tsegismont at gmail.com  Tue Oct 10 05:08:01 2017
From: tsegismont at gmail.com (Thomas SEGISMONT)
Date: Tue, 10 Oct 2017 11:08:01 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
Message-ID: <CACiEr_QH9oqxydVJg8+aEaamEVK5KFAfOEnoiyRQv7u12a-w-g@mail.gmail.com>

2017-10-09 18:30 GMT+02:00 Radim Vansa <rvansa at redhat.com>:

> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
> > Hi,
> >
> > I've created a branch in vertx-infinispan to start incorporating the
> > new features in 9.2.
> >
> > https://github.com/vert-x3/vertx-infinispan/tree/ispn92
> > <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
> >
> > Here are a couple of comments/concerns on MultimapCache:
> > 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
> > MultimapCacheManager; it would be nice to have type arguments instead,
> > to avoid unchecked assignment warnings
> > 2/ MultimapCache does not accept entry listeners. We use them to build
> > a near cache to increase the speed of sending
>
> Do you need clustered listeners or only those on owners? Btw., you can
> register a listener on the underlying cache, but I agree that an
> interface that will adapt it correctly (e.g. mapping @EntryModified on
> multi-value to @EntryCreated on the new value) would appear less crude.
>

We need clustered listeners because any member should be able to update its
near cache.

If a listener is registered on the underlying cache, the event payload
would be the full collection when an element is added/removed from the
multimap cache?


>
> R.
>
> >
> > 1/ is easy, but do you think 2/ could be added in 9.2?
> >
> > Thank you,
> > Thomas
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> 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/20171010/56a6a1f8/attachment.html 

From tsegismont at gmail.com  Tue Oct 10 05:13:30 2017
From: tsegismont at gmail.com (Thomas SEGISMONT)
Date: Tue, 10 Oct 2017 11:13:30 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <E9B7C8F5-A973-4816-809C-C6EC7F1DDAC7@hibernate.org>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
	<E9B7C8F5-A973-4816-809C-C6EC7F1DDAC7@hibernate.org>
Message-ID: <CACiEr_S+JWRthmVWLeCR1eQmnCttVe03_ai3x3BipSW1H6=OPA@mail.gmail.com>

We don't use the Infinispan client, we use Infinispan embedded. We could
use Infinispan Client if there were:
- an API for retrieving a list of connected clients (preferably w/ some
properties, like when I connect I tell the server I want to join the Vert.x
cluster)
- events when other clients connect/leave

Besides multimap is available for embedded mode right now. I'm not sure but
I believe it's the same for clustered counters.

2017-10-09 19:21 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> Stupid question. Hot Rod does not have near cache invalidation already ?
> Does not suit your needs or not implemented for multimapcache?
>
> > On 9 Oct 2017, at 18:30, Radim Vansa <rvansa at redhat.com> wrote:
> >
> >> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
> >> Hi,
> >>
> >> I've created a branch in vertx-infinispan to start incorporating the
> >> new features in 9.2.
> >>
> >> https://github.com/vert-x3/vertx-infinispan/tree/ispn92
> >> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
> >>
> >> Here are a couple of comments/concerns on MultimapCache:
> >> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
> >> MultimapCacheManager; it would be nice to have type arguments instead,
> >> to avoid unchecked assignment warnings
> >> 2/ MultimapCache does not accept entry listeners. We use them to build
> >> a near cache to increase the speed of sending
> >
> > Do you need clustered listeners or only those on owners? Btw., you can
> > register a listener on the underlying cache, but I agree that an
> > interface that will adapt it correctly (e.g. mapping @EntryModified on
> > multi-value to @EntryCreated on the new value) would appear less crude.
> >
> > R.
> >
> >>
> >> 1/ is easy, but do you think 2/ could be added in 9.2?
> >>
> >> Thank you,
> >> Thomas
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > --
> > Radim Vansa <rvansa at redhat.com>
> > JBoss Performance Team
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171010/32d9f3f5/attachment.html 

From karesti at redhat.com  Tue Oct 10 05:22:15 2017
From: karesti at redhat.com (Katia Aresti)
Date: Tue, 10 Oct 2017 11:22:15 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <E9B7C8F5-A973-4816-809C-C6EC7F1DDAC7@hibernate.org>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
	<E9B7C8F5-A973-4816-809C-C6EC7F1DDAC7@hibernate.org>
Message-ID: <CAKypdvkzJNRjfJ6qxsk_gqP17GS1--0SbNwUUV2_Y9O9HNnLHA@mail.gmail.com>

Hi Thomas,

Thank you for the first feedback ! :)
We can add listeners on the cache directly, yes, but without specific
listeners, the payload will contain all the values. I'm going to check with
the team to estimate the modifications needed and the impact for this
particular case.

Concerning hotrod, even if this is not used for vert.x cluster manager,
Multimap will support it soon :)

Katia


On Mon, Oct 9, 2017 at 7:21 PM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Stupid question. Hot Rod does not have near cache invalidation already ?
> Does not suit your needs or not implemented for multimapcache?
>
> > On 9 Oct 2017, at 18:30, Radim Vansa <rvansa at redhat.com> wrote:
> >
> >> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
> >> Hi,
> >>
> >> I've created a branch in vertx-infinispan to start incorporating the
> >> new features in 9.2.
> >>
> >> https://github.com/vert-x3/vertx-infinispan/tree/ispn92
> >> <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
> >>
> >> Here are a couple of comments/concerns on MultimapCache:
> >> 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
> >> MultimapCacheManager; it would be nice to have type arguments instead,
> >> to avoid unchecked assignment warnings
> >> 2/ MultimapCache does not accept entry listeners. We use them to build
> >> a near cache to increase the speed of sending
> >
> > Do you need clustered listeners or only those on owners? Btw., you can
> > register a listener on the underlying cache, but I agree that an
> > interface that will adapt it correctly (e.g. mapping @EntryModified on
> > multi-value to @EntryCreated on the new value) would appear less crude.
> >
> > R.
> >
> >>
> >> 1/ is easy, but do you think 2/ could be added in 9.2?
> >>
> >> Thank you,
> >> Thomas
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > --
> > Radim Vansa <rvansa at redhat.com>
> > JBoss Performance Team
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171010/d638b00a/attachment-0001.html 

From pedro at infinispan.org  Tue Oct 10 05:26:39 2017
From: pedro at infinispan.org (Pedro Ruivo)
Date: Tue, 10 Oct 2017 10:26:39 +0100
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <CACiEr_S+JWRthmVWLeCR1eQmnCttVe03_ai3x3BipSW1H6=OPA@mail.gmail.com>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
	<E9B7C8F5-A973-4816-809C-C6EC7F1DDAC7@hibernate.org>
	<CACiEr_S+JWRthmVWLeCR1eQmnCttVe03_ai3x3BipSW1H6=OPA@mail.gmail.com>
Message-ID: <0a1c8cf6-03d3-0943-6f0c-2ecdf05cf841@infinispan.org>



On 10-10-2017 10:13, Thomas SEGISMONT wrote:
> Besides multimap is available for embedded mode right now. I'm not sure 
> but I believe it's the same for clustered counters.

Yes the counters are available in Embedded. They will be added to Hot 
Rod soon.

From rvansa at redhat.com  Tue Oct 10 09:03:50 2017
From: rvansa at redhat.com (Radim Vansa)
Date: Tue, 10 Oct 2017 15:03:50 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <CACiEr_QH9oqxydVJg8+aEaamEVK5KFAfOEnoiyRQv7u12a-w-g@mail.gmail.com>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
	<CACiEr_QH9oqxydVJg8+aEaamEVK5KFAfOEnoiyRQv7u12a-w-g@mail.gmail.com>
Message-ID: <5045ded9-4b00-7ec2-444d-1ded3f95bddd@redhat.com>

On 10/10/2017 11:08 AM, Thomas SEGISMONT wrote:
>
>
> 2017-10-09 18:30 GMT+02:00 Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>>:
>
>     On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
>     > Hi,
>     >
>     > I've created a branch in vertx-infinispan to start incorporating the
>     > new features in 9.2.
>     >
>     > https://github.com/vert-x3/vertx-infinispan/tree/ispn92
>     <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
>     > <https://github.com/vert-x3/vertx-infinispan/tree/ispn92
>     <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>>
>     >
>     > Here are a couple of comments/concerns on MultimapCache:
>     > 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
>     > MultimapCacheManager; it would be nice to have type arguments
>     instead,
>     > to avoid unchecked assignment warnings
>     > 2/ MultimapCache does not accept entry listeners. We use them to
>     build
>     > a near cache to increase the speed of sending
>
>     Do you need clustered listeners or only those on owners? Btw., you can
>     register a listener on the underlying cache, but I agree that an
>     interface that will adapt it correctly (e.g. mapping @EntryModified on
>     multi-value to @EntryCreated on the new value) would appear less
>     crude.
>
>
> We need clustered listeners because any member should be able to 
> update its near cache.
>
> If a listener is registered on the underlying cache, the event payload 
> would be the full collection when an element is added/removed from the 
> multimap cache?

Yes, by default all the values stored under that key. And the event type 
wouldn't be correct. You'd probably want to use addFilteredListener to 
diff previous and current value on owner-side and send only the changed 
entries.

>
>     R.
>
>     >
>     > 1/ is easy, but do you think 2/ could be added in 9.2?
>     >
>     > Thank you,
>     > Thomas
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <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


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


From tsegismont at gmail.com  Tue Oct 10 09:19:07 2017
From: tsegismont at gmail.com (Thomas SEGISMONT)
Date: Tue, 10 Oct 2017 15:19:07 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <0a1c8cf6-03d3-0943-6f0c-2ecdf05cf841@infinispan.org>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
	<E9B7C8F5-A973-4816-809C-C6EC7F1DDAC7@hibernate.org>
	<CACiEr_S+JWRthmVWLeCR1eQmnCttVe03_ai3x3BipSW1H6=OPA@mail.gmail.com>
	<0a1c8cf6-03d3-0943-6f0c-2ecdf05cf841@infinispan.org>
Message-ID: <CACiEr_SmyvJ5yEwh6axiCE23Yh0GDAA4VEZmvf_Gi3spnr8ULA@mail.gmail.com>

2017-10-10 11:26 GMT+02:00 Pedro Ruivo <pedro at infinispan.org>:

>
>
> On 10-10-2017 10:13, Thomas SEGISMONT wrote:
> > Besides multimap is available for embedded mode right now. I'm not sure
> > but I believe it's the same for clustered counters.
>
> Yes the counters are available in Embedded. They will be added to Hot
> Rod soon.
>

Thanks Pedro. I have a question about counters as well, may I proceed here
or do you prefer to discuss it in a separate thread?


> _______________________________________________
> 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/20171010/87ab3b5f/attachment.html 

From pedro at infinispan.org  Tue Oct 10 10:28:49 2017
From: pedro at infinispan.org (Pedro Ruivo)
Date: Tue, 10 Oct 2017 14:28:49 +0000
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <CACiEr_SmyvJ5yEwh6axiCE23Yh0GDAA4VEZmvf_Gi3spnr8ULA@mail.gmail.com>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
	<E9B7C8F5-A973-4816-809C-C6EC7F1DDAC7@hibernate.org>
	<CACiEr_S+JWRthmVWLeCR1eQmnCttVe03_ai3x3BipSW1H6=OPA@mail.gmail.com>
	<0a1c8cf6-03d3-0943-6f0c-2ecdf05cf841@infinispan.org>
	<CACiEr_SmyvJ5yEwh6axiCE23Yh0GDAA4VEZmvf_Gi3spnr8ULA@mail.gmail.com>
Message-ID: <CACwz3KefK-AHg3VCT=kWvizz4NypK8MEhCHq6_gLqYRri0mLsQ@mail.gmail.com>

On Tue, 10 Oct 2017, 15:24 Thomas SEGISMONT, <tsegismont at gmail.com> wrote:

> 2017-10-10 11:26 GMT+02:00 Pedro Ruivo <pedro at infinispan.org>:
>
>>
>>
>> On 10-10-2017 10:13, Thomas SEGISMONT wrote:
>> > Besides multimap is available for embedded mode right now. I'm not sure
>> > but I believe it's the same for clustered counters.
>>
>> Yes the counters are available in Embedded. They will be added to Hot
>> Rod soon.
>>
>
> Thanks Pedro. I have a question about counters as well, may I proceed here
> or do you prefer to discuss it in a separate thread?
>

Please create another thread :)

I might take a while to reply since I'm at airport waiting for my flight.


>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171010/06c0e47f/attachment.html 

From tsegismont at gmail.com  Wed Oct 11 08:52:05 2017
From: tsegismont at gmail.com (Thomas SEGISMONT)
Date: Wed, 11 Oct 2017 14:52:05 +0200
Subject: [infinispan-dev] Feedback on MultimapCache
In-Reply-To: <5045ded9-4b00-7ec2-444d-1ded3f95bddd@redhat.com>
References: <CACiEr_R4-C-zP=JtEA943XG70rjd1_Fh2uHNXKgaWovCqFKR7g@mail.gmail.com>
	<e6b647fc-ab9a-dab4-410e-97119daada5f@redhat.com>
	<CACiEr_QH9oqxydVJg8+aEaamEVK5KFAfOEnoiyRQv7u12a-w-g@mail.gmail.com>
	<5045ded9-4b00-7ec2-444d-1ded3f95bddd@redhat.com>
Message-ID: <CACiEr_Suh+gZ4sNEK=uYDJw5NZJebTdNAngc-rM3NmAVMLHJ6g@mail.gmail.com>

2017-10-10 15:03 GMT+02:00 Radim Vansa <rvansa at redhat.com>:

> On 10/10/2017 11:08 AM, Thomas SEGISMONT wrote:
> >
> >
> > 2017-10-09 18:30 GMT+02:00 Radim Vansa <rvansa at redhat.com
> > <mailto:rvansa at redhat.com>>:
> >
> >     On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
> >     > Hi,
> >     >
> >     > I've created a branch in vertx-infinispan to start incorporating
> the
> >     > new features in 9.2.
> >     >
> >     > https://github.com/vert-x3/vertx-infinispan/tree/ispn92
> >     <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>
> >     > <https://github.com/vert-x3/vertx-infinispan/tree/ispn92
> >     <https://github.com/vert-x3/vertx-infinispan/tree/ispn92>>
> >     >
> >     > Here are a couple of comments/concerns on MultimapCache:
> >     > 1/ EmbeddedMultimapCacheManagerFactory#from returns a raw
> >     > MultimapCacheManager; it would be nice to have type arguments
> >     instead,
> >     > to avoid unchecked assignment warnings
> >     > 2/ MultimapCache does not accept entry listeners. We use them to
> >     build
> >     > a near cache to increase the speed of sending
> >
> >     Do you need clustered listeners or only those on owners? Btw., you
> can
> >     register a listener on the underlying cache, but I agree that an
> >     interface that will adapt it correctly (e.g. mapping @EntryModified
> on
> >     multi-value to @EntryCreated on the new value) would appear less
> >     crude.
> >
> >
> > We need clustered listeners because any member should be able to
> > update its near cache.
> >
> > If a listener is registered on the underlying cache, the event payload
> > would be the full collection when an element is added/removed from the
> > multimap cache?
>
> Yes, by default all the values stored under that key. And the event type
> wouldn't be correct. You'd probably want to use addFilteredListener to
> diff previous and current value on owner-side and send only the changed
> entries.
>

I ended up doing this and it worked like a charm (see
https://github.com/vert-x3/vertx-infinispan/commit/ff2b541f52086578e1015937c36e1f2550c85b4f
)

I explored a suggestion from Will regarding L1 caching. But then I realized
we'll always need our own near cache, as we maintain a "ChoosableSet" view
of eventbus handlers (to balance the load)


>
> >
> >     R.
> >
> >     >
> >     > 1/ is easy, but do you think 2/ could be added in 9.2?
> >     >
> >     > Thank you,
> >     > Thomas
> >     >
> >     >
> >     > _______________________________________________
> >     > infinispan-dev mailing list
> >     > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >
> >
> >     --
> >     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
> >     JBoss Performance Team
> >
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.
> jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <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
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> 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/20171011/9c67ac45/attachment-0001.html 

From ttarrant at redhat.com  Mon Oct 16 02:49:27 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 16 Oct 2017 08:49:27 +0200
Subject: [infinispan-dev] CFV: Close Infinispan user forum in favour of
	StackOverflow
Message-ID: <e2795108-b964-2017-fd29-f507cd803c37@redhat.com>

Dear all,

last week we discussed the possibility of closing our Infinispan user 
forum [1] and redirecting users to StackOverflow instead. This would 
have a number of advantages:

- wider audience
- encourages non-team members to provide answers
- better visibility in search engines


We have also discussed the possibility of a user-oriented "mailing list" 
on Google Groups for more articulate discussions. We can even consider 
migrating this list over there.

Comments are welcome and encouraged

Tristan

[1] https://developer.jboss.org/en/infinispan/content

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

From ttarrant at redhat.com  Mon Oct 16 04:27:30 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 16 Oct 2017 10:27:30 +0200
Subject: [infinispan-dev] Replacing IRC
Message-ID: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>

Dear all,

last week we discussed the possibility of abandoning IRC in favour of a 
more modern alternative.

Hard requirements:
- free (as in beer)
- hosted (we don't want to maintain it ourselves)
- multi-platform client: native (Linux, MacOS, Windows), browser
- persistent logs
- distinction between channel operators and normal users
- guest access (without the need for registration)
- integration with Jira for issue lookup
- integration with GitHub for PR lookup
- IRC bridge (so that users can connect with an IRC client)
- ability to export data in case we want to move somewhere else
- on-the-fly room creation for mini-teams

Optionals:
- Free (as in freedom)
- offline notifications (i.e. see if I was notified while away)
- mobile client: Android and iOS
- proper native client (as most Electron clients are quite fat)
- chat logs accessible without a client (it is acceptable if this is 
achieved via a bot)
- integration with Jenkins for CI status
- XMPP bridge (so that users can connect with an XMPP client)

Not needed:
- file sharing, audio/video

Here is a list of candidates:
- IRC (i.e. no change)
- Slack
- Stride (Atlassian's upcoming replacement for HipChat)
- Matrix (Matrix.org, unfortunately with funding issues)
- Gitter
- Discord
- Rocket.chat (unfortunately hosting is paid)

If you have any other suggestions/recommendations, they are more than 
welcome.

Tristan

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

From sanne at infinispan.org  Mon Oct 16 05:13:06 2017
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 16 Oct 2017 11:13:06 +0200
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
Message-ID: <CAFm4XO0zrDkDMwoebvudyDurP81DJUDznpQoHh52mm1BAO5Fbw@mail.gmail.com>

Some of us do a lot of communications / planning related work on
tablets & similar, and I assume that this trend will increase in the
future.
E.g. I regularly catch up on projects activity from the smartphone.

May I suggest the "mobile client" to be considered an hard
requirement? Changing communication channels is disruptive for the
community so better make a future-proof choice.

You all know I'm quite happy with the stuff produced by Atlassian, so
I haven't seen Stride in action yet but I'm confident it will be
great: they aren't making a general purpose chat platform but a
collaboration tool having specifically in mind distributed software
development.

I also tried Gitter in the past, another tool awesomely integrated
with github, therefore also developer oriented. We had to abandon it
as it required all-in permissions on Github, but that was in its early
days (some years ago?) so I guess this might have been resolved by
now.

Thanks for taking these in consideration! Looking forward to see what
others think.
 - Sanne




On 16 October 2017 at 10:27, Tristan Tarrant <ttarrant at redhat.com> wrote:
> Dear all,
>
> last week we discussed the possibility of abandoning IRC in favour of a
> more modern alternative.
>
> Hard requirements:
> - free (as in beer)
> - hosted (we don't want to maintain it ourselves)
> - multi-platform client: native (Linux, MacOS, Windows), browser
> - persistent logs
> - distinction between channel operators and normal users
> - guest access (without the need for registration)
> - integration with Jira for issue lookup
> - integration with GitHub for PR lookup
> - IRC bridge (so that users can connect with an IRC client)
> - ability to export data in case we want to move somewhere else
> - on-the-fly room creation for mini-teams
>
> Optionals:
> - Free (as in freedom)
> - offline notifications (i.e. see if I was notified while away)
> - mobile client: Android and iOS
> - proper native client (as most Electron clients are quite fat)
> - chat logs accessible without a client (it is acceptable if this is
> achieved via a bot)
> - integration with Jenkins for CI status
> - XMPP bridge (so that users can connect with an XMPP client)
>
> Not needed:
> - file sharing, audio/video
>
> Here is a list of candidates:
> - IRC (i.e. no change)
> - Slack
> - Stride (Atlassian's upcoming replacement for HipChat)
> - Matrix (Matrix.org, unfortunately with funding issues)
> - Gitter
> - Discord
> - Rocket.chat (unfortunately hosting is paid)
>
> If you have any other suggestions/recommendations, they are more than
> welcome.
>
> Tristan
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From wfink at redhat.com  Mon Oct 16 05:16:33 2017
From: wfink at redhat.com (Wolf Fink)
Date: Mon, 16 Oct 2017 11:16:33 +0200
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
Message-ID: <CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>

Why not use Hipchat as EAP/Wildfly to prevent from too many different
platforms ?

On Mon, Oct 16, 2017 at 10:27 AM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> Dear all,
>
> last week we discussed the possibility of abandoning IRC in favour of a
> more modern alternative.
>
> Hard requirements:
> - free (as in beer)
> - hosted (we don't want to maintain it ourselves)
> - multi-platform client: native (Linux, MacOS, Windows), browser
> - persistent logs
> - distinction between channel operators and normal users
> - guest access (without the need for registration)
> - integration with Jira for issue lookup
> - integration with GitHub for PR lookup
> - IRC bridge (so that users can connect with an IRC client)
> - ability to export data in case we want to move somewhere else
> - on-the-fly room creation for mini-teams
>
> Optionals:
> - Free (as in freedom)
> - offline notifications (i.e. see if I was notified while away)
> - mobile client: Android and iOS
> - proper native client (as most Electron clients are quite fat)
> - chat logs accessible without a client (it is acceptable if this is
> achieved via a bot)
> - integration with Jenkins for CI status
> - XMPP bridge (so that users can connect with an XMPP client)
>
> Not needed:
> - file sharing, audio/video
>
> Here is a list of candidates:
> - IRC (i.e. no change)
> - Slack
> - Stride (Atlassian's upcoming replacement for HipChat)
> - Matrix (Matrix.org, unfortunately with funding issues)
> - Gitter
> - Discord
> - Rocket.chat (unfortunately hosting is paid)
>
> If you have any other suggestions/recommendations, they are more than
> welcome.
>
> Tristan
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171016/51ee50cf/attachment.html 

From ttarrant at redhat.com  Mon Oct 16 05:29:01 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 16 Oct 2017 11:29:01 +0200
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
	<CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>
Message-ID: <ed76c44b-be0e-d1a3-4deb-b1376db43c1b@redhat.com>

HipChat is being replaced by Stride.
I have dimissed HipChat in the past because it did not allow for a 
single account to be shared across multiple groups. I believe this will 
be solved by Stride.

Tristan

On 10/16/17 11:16 AM, Wolf Fink wrote:
> Why not use Hipchat as EAP/Wildfly to prevent from too many different 
> platforms ?
> 
> On Mon, Oct 16, 2017 at 10:27 AM, Tristan Tarrant <ttarrant at redhat.com 
> <mailto:ttarrant at redhat.com>> wrote:
> 
>     Dear all,
> 
>     last week we discussed the possibility of abandoning IRC in favour of a
>     more modern alternative.
> 
>     Hard requirements:
>     - free (as in beer)
>     - hosted (we don't want to maintain it ourselves)
>     - multi-platform client: native (Linux, MacOS, Windows), browser
>     - persistent logs
>     - distinction between channel operators and normal users
>     - guest access (without the need for registration)
>     - integration with Jira for issue lookup
>     - integration with GitHub for PR lookup
>     - IRC bridge (so that users can connect with an IRC client)
>     - ability to export data in case we want to move somewhere else
>     - on-the-fly room creation for mini-teams
> 
>     Optionals:
>     - Free (as in freedom)
>     - offline notifications (i.e. see if I was notified while away)
>     - mobile client: Android and iOS
>     - proper native client (as most Electron clients are quite fat)
>     - chat logs accessible without a client (it is acceptable if this is
>     achieved via a bot)
>     - integration with Jenkins for CI status
>     - XMPP bridge (so that users can connect with an XMPP client)
> 
>     Not needed:
>     - file sharing, audio/video
> 
>     Here is a list of candidates:
>     - IRC (i.e. no change)
>     - Slack
>     - Stride (Atlassian's upcoming replacement for HipChat)
>     - Matrix (Matrix.org, unfortunately with funding issues)
>     - Gitter
>     - Discord
>     - Rocket.chat (unfortunately hosting is paid)
> 
>     If you have any other suggestions/recommendations, they are more than
>     welcome.
> 
>     Tristan
> 
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

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

From karesti at redhat.com  Mon Oct 16 08:45:34 2017
From: karesti at redhat.com (Katia Aresti)
Date: Mon, 16 Oct 2017 14:45:34 +0200
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <ed76c44b-be0e-d1a3-4deb-b1376db43c1b@redhat.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
	<CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>
	<ed76c44b-be0e-d1a3-4deb-b1376db43c1b@redhat.com>
Message-ID: <CAKypdvk3ehb+87QcatjFcpb6qQ2hUi8eac6jZq_fj+My=7jYiA@mail.gmail.com>

Hi all,

I'm a strong adopter of slack and I really like it. I've used it since it
came out with Duchess (we started with an internal use for the team, and we
have a community slack now with more that 150 people there that is little
by little replacing our google group). I've use it in different
communities, startups and big company client's teams. As far as I know,
other open-source projects have already adopted it successfully.
What is cool about it is that joining any team and switching from one team
to another is very easy. If people want to join the community, and they are
already using slack, is very easy.

I agree with Sanne, being able to use it from the smartphone is important
and could be considered as a high requirement. I use slack on my phone, and
it helps quit a lot. Most of the time I use it from my laptop, but there
are cases where mobile has really helped us (specially in Duchess France
slack). I use the native slack client on my mac and works very well.

I haven't tested Stride or Gitter.

Katia





On Mon, Oct 16, 2017 at 11:29 AM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> HipChat is being replaced by Stride.
> I have dimissed HipChat in the past because it did not allow for a
> single account to be shared across multiple groups. I believe this will
> be solved by Stride.
>
> Tristan
>
> On 10/16/17 11:16 AM, Wolf Fink wrote:
> > Why not use Hipchat as EAP/Wildfly to prevent from too many different
> > platforms ?
> >
> > On Mon, Oct 16, 2017 at 10:27 AM, Tristan Tarrant <ttarrant at redhat.com
> > <mailto:ttarrant at redhat.com>> wrote:
> >
> >     Dear all,
> >
> >     last week we discussed the possibility of abandoning IRC in favour
> of a
> >     more modern alternative.
> >
> >     Hard requirements:
> >     - free (as in beer)
> >     - hosted (we don't want to maintain it ourselves)
> >     - multi-platform client: native (Linux, MacOS, Windows), browser
> >     - persistent logs
> >     - distinction between channel operators and normal users
> >     - guest access (without the need for registration)
> >     - integration with Jira for issue lookup
> >     - integration with GitHub for PR lookup
> >     - IRC bridge (so that users can connect with an IRC client)
> >     - ability to export data in case we want to move somewhere else
> >     - on-the-fly room creation for mini-teams
> >
> >     Optionals:
> >     - Free (as in freedom)
> >     - offline notifications (i.e. see if I was notified while away)
> >     - mobile client: Android and iOS
> >     - proper native client (as most Electron clients are quite fat)
> >     - chat logs accessible without a client (it is acceptable if this is
> >     achieved via a bot)
> >     - integration with Jenkins for CI status
> >     - XMPP bridge (so that users can connect with an XMPP client)
> >
> >     Not needed:
> >     - file sharing, audio/video
> >
> >     Here is a list of candidates:
> >     - IRC (i.e. no change)
> >     - Slack
> >     - Stride (Atlassian's upcoming replacement for HipChat)
> >     - Matrix (Matrix.org, unfortunately with funding issues)
> >     - Gitter
> >     - Discord
> >     - Rocket.chat (unfortunately hosting is paid)
> >
> >     If you have any other suggestions/recommendations, they are more than
> >     welcome.
> >
> >     Tristan
> >
> >     --
> >     Tristan Tarrant
> >     Infinispan Lead
> >     JBoss, a division of Red Hat
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.
> jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> 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/20171016/2e467493/attachment-0001.html 

From slaskawi at redhat.com  Wed Oct 18 03:52:40 2017
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 18 Oct 2017 07:52:40 +0000
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <CAKypdvk3ehb+87QcatjFcpb6qQ2hUi8eac6jZq_fj+My=7jYiA@mail.gmail.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
	<CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>
	<ed76c44b-be0e-d1a3-4deb-b1376db43c1b@redhat.com>
	<CAKypdvk3ehb+87QcatjFcpb6qQ2hUi8eac6jZq_fj+My=7jYiA@mail.gmail.com>
Message-ID: <CAA9R9O4Qufo2YdjA2ruaUB60HgkK-Xzav+X8to-E9ip4Hw_N-w@mail.gmail.com>

+1 to Slack. All JUG communities I know are using it. It is also worth to
mention that Slack was also adopted by Kubernetes folks.

On Mon, Oct 16, 2017 at 4:17 PM Katia Aresti <karesti at redhat.com> wrote:

> Hi all,
>
> I'm a strong adopter of slack and I really like it. I've used it since it
> came out with Duchess (we started with an internal use for the team, and we
> have a community slack now with more that 150 people there that is little
> by little replacing our google group). I've use it in different
> communities, startups and big company client's teams. As far as I know,
> other open-source projects have already adopted it successfully.
> What is cool about it is that joining any team and switching from one team
> to another is very easy. If people want to join the community, and they are
> already using slack, is very easy.
>
> I agree with Sanne, being able to use it from the smartphone is important
> and could be considered as a high requirement. I use slack on my phone, and
> it helps quit a lot. Most of the time I use it from my laptop, but there
> are cases where mobile has really helped us (specially in Duchess France
> slack). I use the native slack client on my mac and works very well.
>
> I haven't tested Stride or Gitter.
>
> Katia
>
>
>
>
>
> On Mon, Oct 16, 2017 at 11:29 AM, Tristan Tarrant <ttarrant at redhat.com>
> wrote:
>
>> HipChat is being replaced by Stride.
>> I have dimissed HipChat in the past because it did not allow for a
>> single account to be shared across multiple groups. I believe this will
>> be solved by Stride.
>>
>> Tristan
>>
>> On 10/16/17 11:16 AM, Wolf Fink wrote:
>> > Why not use Hipchat as EAP/Wildfly to prevent from too many different
>> > platforms ?
>> >
>> > On Mon, Oct 16, 2017 at 10:27 AM, Tristan Tarrant <ttarrant at redhat.com
>> > <mailto:ttarrant at redhat.com>> wrote:
>> >
>> >     Dear all,
>> >
>> >     last week we discussed the possibility of abandoning IRC in favour
>> of a
>> >     more modern alternative.
>> >
>> >     Hard requirements:
>> >     - free (as in beer)
>> >     - hosted (we don't want to maintain it ourselves)
>> >     - multi-platform client: native (Linux, MacOS, Windows), browser
>> >     - persistent logs
>> >     - distinction between channel operators and normal users
>> >     - guest access (without the need for registration)
>> >     - integration with Jira for issue lookup
>> >     - integration with GitHub for PR lookup
>> >     - IRC bridge (so that users can connect with an IRC client)
>> >     - ability to export data in case we want to move somewhere else
>> >     - on-the-fly room creation for mini-teams
>> >
>> >     Optionals:
>> >     - Free (as in freedom)
>> >     - offline notifications (i.e. see if I was notified while away)
>> >     - mobile client: Android and iOS
>> >     - proper native client (as most Electron clients are quite fat)
>> >     - chat logs accessible without a client (it is acceptable if this is
>> >     achieved via a bot)
>> >     - integration with Jenkins for CI status
>> >     - XMPP bridge (so that users can connect with an XMPP client)
>> >
>> >     Not needed:
>> >     - file sharing, audio/video
>> >
>> >     Here is a list of candidates:
>> >     - IRC (i.e. no change)
>> >     - Slack
>> >     - Stride (Atlassian's upcoming replacement for HipChat)
>> >     - Matrix (Matrix.org, unfortunately with funding issues)
>> >     - Gitter
>> >     - Discord
>> >     - Rocket.chat (unfortunately hosting is paid)
>> >
>> >     If you have any other suggestions/recommendations, they are more
>> than
>> >     welcome.
>> >
>> >     Tristan
>> >
>> >     --
>> >     Tristan Tarrant
>> >     Infinispan Lead
>> >     JBoss, a division of Red Hat
>> >     _______________________________________________
>> >     infinispan-dev mailing list
>> >     infinispan-dev at lists.jboss.org <mailto:
>> infinispan-dev at lists.jboss.org>
>> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>> >
>> >
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171018/a02f7413/attachment.html 

From vblagoje at redhat.com  Wed Oct 18 07:09:07 2017
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Wed, 18 Oct 2017 07:09:07 -0400
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <CAKypdvk3ehb+87QcatjFcpb6qQ2hUi8eac6jZq_fj+My=7jYiA@mail.gmail.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
	<CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>
	<ed76c44b-be0e-d1a3-4deb-b1376db43c1b@redhat.com>
	<CAKypdvk3ehb+87QcatjFcpb6qQ2hUi8eac6jZq_fj+My=7jYiA@mail.gmail.com>
Message-ID: <92730403-3543-7372-57d8-63824a7e9e0e@redhat.com>

Some updates on memory issues we talked about 
https://slack.engineering/reducing-slacks-memory-footprint-4480fec7e8eb

I looked at Stride briefly and it also looks very promising with its 
actions and decisions focus and deep integrations with Atlassian stack 
we use anyway!

On 2017-10-16 8:45 AM, Katia Aresti wrote:
> Hi all,
>
> I'm a strong adopter of slack and I really like it. I've used it since 
> it came out with Duchess (we started with an internal use for the 
> team, and we have a community slack now with more that 150 people 
> there that is little by little replacing our google group). I've use 
> it in different communities, startups and big company client's teams. 
> As far as I know, other open-source projects have already adopted it 
> successfully.
> What is cool about it is that joining any team and switching from one 
> team to another is very easy. If people want to join the community, 
> and they are already using slack, is very easy.
>
> I agree with Sanne, being able to use it from the smartphone is 
> important and could be considered as a high requirement. I use slack 
> on my phone, and it helps quit a lot. Most of the time I use it from 
> my laptop, but there are cases where mobile has really helped us 
> (specially in Duchess France slack). I use the native slack client on 
> my mac and works very well.
>
> I haven't tested Stride or Gitter.
>
> Katia
>
>
>
>
>
> On Mon, Oct 16, 2017 at 11:29 AM, Tristan Tarrant <ttarrant at redhat.com 
> <mailto:ttarrant at redhat.com>> wrote:
>
>     HipChat is being replaced by Stride.
>     I have dimissed HipChat in the past because it did not allow for a
>     single account to be shared across multiple groups. I believe this
>     will
>     be solved by Stride.
>
>     Tristan
>

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

From sanne at infinispan.org  Wed Oct 18 10:58:25 2017
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 18 Oct 2017 16:58:25 +0200
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <CAA9R9O4Qufo2YdjA2ruaUB60HgkK-Xzav+X8to-E9ip4Hw_N-w@mail.gmail.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
	<CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>
	<ed76c44b-be0e-d1a3-4deb-b1376db43c1b@redhat.com>
	<CAKypdvk3ehb+87QcatjFcpb6qQ2hUi8eac6jZq_fj+My=7jYiA@mail.gmail.com>
	<CAA9R9O4Qufo2YdjA2ruaUB60HgkK-Xzav+X8to-E9ip4Hw_N-w@mail.gmail.com>
Message-ID: <CAFm4XO0_7mzxUyGBPTnX9iNhDMmGrhAHChGQO-jfnx_BpLVa_w@mail.gmail.com>

Sorry but I'm not going to use slack, I for one are planning to put my
system resources to better use.

On 18 Oct 2017 3:23 pm, "Sebastian Laskawiec" <slaskawi at redhat.com> wrote:

> +1 to Slack. All JUG communities I know are using it. It is also worth to
> mention that Slack was also adopted by Kubernetes folks.
>
> On Mon, Oct 16, 2017 at 4:17 PM Katia Aresti <karesti at redhat.com> wrote:
>
>> Hi all,
>>
>> I'm a strong adopter of slack and I really like it. I've used it since it
>> came out with Duchess (we started with an internal use for the team, and we
>> have a community slack now with more that 150 people there that is little
>> by little replacing our google group). I've use it in different
>> communities, startups and big company client's teams. As far as I know,
>> other open-source projects have already adopted it successfully.
>> What is cool about it is that joining any team and switching from one
>> team to another is very easy. If people want to join the community, and
>> they are already using slack, is very easy.
>>
>> I agree with Sanne, being able to use it from the smartphone is important
>> and could be considered as a high requirement. I use slack on my phone, and
>> it helps quit a lot. Most of the time I use it from my laptop, but there
>> are cases where mobile has really helped us (specially in Duchess France
>> slack). I use the native slack client on my mac and works very well.
>>
>> I haven't tested Stride or Gitter.
>>
>> Katia
>>
>>
>>
>>
>>
>> On Mon, Oct 16, 2017 at 11:29 AM, Tristan Tarrant <ttarrant at redhat.com>
>> wrote:
>>
>>> HipChat is being replaced by Stride.
>>> I have dimissed HipChat in the past because it did not allow for a
>>> single account to be shared across multiple groups. I believe this will
>>> be solved by Stride.
>>>
>>> Tristan
>>>
>>> On 10/16/17 11:16 AM, Wolf Fink wrote:
>>> > Why not use Hipchat as EAP/Wildfly to prevent from too many different
>>> > platforms ?
>>> >
>>> > On Mon, Oct 16, 2017 at 10:27 AM, Tristan Tarrant <ttarrant at redhat.com
>>> > <mailto:ttarrant at redhat.com>> wrote:
>>> >
>>> >     Dear all,
>>> >
>>> >     last week we discussed the possibility of abandoning IRC in favour
>>> of a
>>> >     more modern alternative.
>>> >
>>> >     Hard requirements:
>>> >     - free (as in beer)
>>> >     - hosted (we don't want to maintain it ourselves)
>>> >     - multi-platform client: native (Linux, MacOS, Windows), browser
>>> >     - persistent logs
>>> >     - distinction between channel operators and normal users
>>> >     - guest access (without the need for registration)
>>> >     - integration with Jira for issue lookup
>>> >     - integration with GitHub for PR lookup
>>> >     - IRC bridge (so that users can connect with an IRC client)
>>> >     - ability to export data in case we want to move somewhere else
>>> >     - on-the-fly room creation for mini-teams
>>> >
>>> >     Optionals:
>>> >     - Free (as in freedom)
>>> >     - offline notifications (i.e. see if I was notified while away)
>>> >     - mobile client: Android and iOS
>>> >     - proper native client (as most Electron clients are quite fat)
>>> >     - chat logs accessible without a client (it is acceptable if this
>>> is
>>> >     achieved via a bot)
>>> >     - integration with Jenkins for CI status
>>> >     - XMPP bridge (so that users can connect with an XMPP client)
>>> >
>>> >     Not needed:
>>> >     - file sharing, audio/video
>>> >
>>> >     Here is a list of candidates:
>>> >     - IRC (i.e. no change)
>>> >     - Slack
>>> >     - Stride (Atlassian's upcoming replacement for HipChat)
>>> >     - Matrix (Matrix.org, unfortunately with funding issues)
>>> >     - Gitter
>>> >     - Discord
>>> >     - Rocket.chat (unfortunately hosting is paid)
>>> >
>>> >     If you have any other suggestions/recommendations, they are more
>>> than
>>> >     welcome.
>>> >
>>> >     Tristan
>>> >
>>> >     --
>>> >     Tristan Tarrant
>>> >     Infinispan Lead
>>> >     JBoss, a division of Red Hat
>>> >     _______________________________________________
>>> >     infinispan-dev mailing list
>>> >     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.
>>> jboss.org>
>>> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > infinispan-dev mailing list
>>> > infinispan-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >
>>>
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171018/272e9c12/attachment-0001.html 

From dan.berindei at gmail.com  Wed Oct 18 11:24:37 2017
From: dan.berindei at gmail.com (Dan Berindei)
Date: Wed, 18 Oct 2017 18:24:37 +0300
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <CAA9R9O4Qufo2YdjA2ruaUB60HgkK-Xzav+X8to-E9ip4Hw_N-w@mail.gmail.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
	<CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>
	<ed76c44b-be0e-d1a3-4deb-b1376db43c1b@redhat.com>
	<CAKypdvk3ehb+87QcatjFcpb6qQ2hUi8eac6jZq_fj+My=7jYiA@mail.gmail.com>
	<CAA9R9O4Qufo2YdjA2ruaUB60HgkK-Xzav+X8to-E9ip4Hw_N-w@mail.gmail.com>
Message-ID: <CA+nfvwT9EyC95puVJC3-Qt07LkB3Kzd0fuN8FHBEDtaPFizAgw@mail.gmail.com>

Discourse [1] is more of a forum replacement than a chat, but I'd
still like to suggest it. I hate it how in IRC you never know when a
user has finished their idea and it's safe to start replying, and
typing notifications don't really work for me :)

Dan

[1]: https://meta.discourse.org/



On Wed, Oct 18, 2017 at 10:52 AM, Sebastian Laskawiec
<slaskawi at redhat.com> wrote:
> +1 to Slack. All JUG communities I know are using it. It is also worth to
> mention that Slack was also adopted by Kubernetes folks.
>
> On Mon, Oct 16, 2017 at 4:17 PM Katia Aresti <karesti at redhat.com> wrote:
>>
>> Hi all,
>>
>> I'm a strong adopter of slack and I really like it. I've used it since it
>> came out with Duchess (we started with an internal use for the team, and we
>> have a community slack now with more that 150 people there that is little by
>> little replacing our google group). I've use it in different communities,
>> startups and big company client's teams. As far as I know, other open-source
>> projects have already adopted it successfully.
>> What is cool about it is that joining any team and switching from one team
>> to another is very easy. If people want to join the community, and they are
>> already using slack, is very easy.
>>
>> I agree with Sanne, being able to use it from the smartphone is important
>> and could be considered as a high requirement. I use slack on my phone, and
>> it helps quit a lot. Most of the time I use it from my laptop, but there are
>> cases where mobile has really helped us (specially in Duchess France slack).
>> I use the native slack client on my mac and works very well.
>>
>> I haven't tested Stride or Gitter.
>>
>> Katia
>>
>>
>>
>>
>>
>> On Mon, Oct 16, 2017 at 11:29 AM, Tristan Tarrant <ttarrant at redhat.com>
>> wrote:
>>>
>>> HipChat is being replaced by Stride.
>>> I have dimissed HipChat in the past because it did not allow for a
>>> single account to be shared across multiple groups. I believe this will
>>> be solved by Stride.
>>>
>>> Tristan
>>>
>>> On 10/16/17 11:16 AM, Wolf Fink wrote:
>>> > Why not use Hipchat as EAP/Wildfly to prevent from too many different
>>> > platforms ?
>>> >
>>> > On Mon, Oct 16, 2017 at 10:27 AM, Tristan Tarrant <ttarrant at redhat.com
>>> > <mailto:ttarrant at redhat.com>> wrote:
>>> >
>>> >     Dear all,
>>> >
>>> >     last week we discussed the possibility of abandoning IRC in favour
>>> > of a
>>> >     more modern alternative.
>>> >
>>> >     Hard requirements:
>>> >     - free (as in beer)
>>> >     - hosted (we don't want to maintain it ourselves)
>>> >     - multi-platform client: native (Linux, MacOS, Windows), browser
>>> >     - persistent logs
>>> >     - distinction between channel operators and normal users
>>> >     - guest access (without the need for registration)
>>> >     - integration with Jira for issue lookup
>>> >     - integration with GitHub for PR lookup
>>> >     - IRC bridge (so that users can connect with an IRC client)
>>> >     - ability to export data in case we want to move somewhere else
>>> >     - on-the-fly room creation for mini-teams
>>> >
>>> >     Optionals:
>>> >     - Free (as in freedom)
>>> >     - offline notifications (i.e. see if I was notified while away)
>>> >     - mobile client: Android and iOS
>>> >     - proper native client (as most Electron clients are quite fat)
>>> >     - chat logs accessible without a client (it is acceptable if this
>>> > is
>>> >     achieved via a bot)
>>> >     - integration with Jenkins for CI status
>>> >     - XMPP bridge (so that users can connect with an XMPP client)
>>> >
>>> >     Not needed:
>>> >     - file sharing, audio/video
>>> >
>>> >     Here is a list of candidates:
>>> >     - IRC (i.e. no change)
>>> >     - Slack
>>> >     - Stride (Atlassian's upcoming replacement for HipChat)
>>> >     - Matrix (Matrix.org, unfortunately with funding issues)
>>> >     - Gitter
>>> >     - Discord
>>> >     - Rocket.chat (unfortunately hosting is paid)
>>> >
>>> >     If you have any other suggestions/recommendations, they are more
>>> > than
>>> >     welcome.
>>> >
>>> >     Tristan
>>> >
>>> >     --
>>> >     Tristan Tarrant
>>> >     Infinispan Lead
>>> >     JBoss, a division of Red Hat
>>> >     _______________________________________________
>>> >     infinispan-dev mailing list
>>> >     infinispan-dev at lists.jboss.org
>>> > <mailto:infinispan-dev at lists.jboss.org>
>>> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > infinispan-dev mailing list
>>> > infinispan-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >
>>>
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From ttarrant at redhat.com  Wed Oct 18 13:49:38 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 18 Oct 2017 19:49:38 +0200
Subject: [infinispan-dev] Replacing IRC
In-Reply-To: <92730403-3543-7372-57d8-63824a7e9e0e@redhat.com>
References: <02998599-bc00-d335-e2d1-ee89c2ea0b1d@redhat.com>
	<CAKwmrdOeeAw8SWnJ2xSmJJraNwrgn2RNvNu-+Xfa1Ldq_z+bvw@mail.gmail.com>
	<ed76c44b-be0e-d1a3-4deb-b1376db43c1b@redhat.com>
	<CAKypdvk3ehb+87QcatjFcpb6qQ2hUi8eac6jZq_fj+My=7jYiA@mail.gmail.com>
	<92730403-3543-7372-57d8-63824a7e9e0e@redhat.com>
Message-ID: <6c9de858-77e3-f943-d328-79a7693434b9@redhat.com>

Yes, I'm currently more tempted to wait for Stride (I have signed up for 
early access).

Tristan

On 10/18/17 1:09 PM, Vladimir Blagojevic wrote:
> Some updates on memory issues we talked about 
> https://slack.engineering/reducing-slacks-memory-footprint-4480fec7e8eb
> 
> I looked at Stride briefly and it also looks very promising with its 
> actions and decisions focus and deep integrations with Atlassian stack 
> we use anyway!
> 
> On 2017-10-16 8:45 AM, Katia Aresti wrote:
>> Hi all,
>>
>> I'm a strong adopter of slack and I really like it. I've used it since 
>> it came out with Duchess (we started with an internal use for the 
>> team, and we have a community slack now with more that 150 people 
>> there that is little by little replacing our google group). I've use 
>> it in different communities, startups and big company client's teams. 
>> As far as I know, other open-source projects have already adopted it 
>> successfully.
>> What is cool about it is that joining any team and switching from one 
>> team to another is very easy. If people want to join the community, 
>> and they are already using slack, is very easy.
>>
>> I agree with Sanne, being able to use it from the smartphone is 
>> important and could be considered as a high requirement. I use slack 
>> on my phone, and it helps quit a lot. Most of the time I use it from 
>> my laptop, but there are cases where mobile has really helped us 
>> (specially in Duchess France slack). I use the native slack client on 
>> my mac and works very well.
>>
>> I haven't tested Stride or Gitter.
>>
>> Katia
>>
>>
>>
>>
>>
>> On Mon, Oct 16, 2017 at 11:29 AM, Tristan Tarrant <ttarrant at redhat.com 
>> <mailto:ttarrant at redhat.com>> wrote:
>>
>>     HipChat is being replaced by Stride.
>>     I have dimissed HipChat in the past because it did not allow for a
>>     single account to be shared across multiple groups. I believe this
>>     will
>>     be solved by Stride.
>>
>>     Tristan
>>
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

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

From ttarrant at redhat.com  Thu Oct 19 10:05:46 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 19 Oct 2017 16:05:46 +0200
Subject: [infinispan-dev] Initial Infinispan driver for JNoSQL
Message-ID: <7a8be28e-ab4c-5796-3cbc-ad337ce8e7ef@redhat.com>

Hi all,

I have just submitted a pull request for an initial driver for JNoSQL

https://github.com/eclipse/jnosql-diana-driver/pull/49

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

From galder at redhat.com  Mon Oct 23 11:51:12 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 23 Oct 2017 17:51:12 +0200
Subject: [infinispan-dev] Protostream marshaller support for optional fields
Message-ID: <3B213514-D2DF-4B1D-82E2-BA9C5445AA43@redhat.com>

Hey Adrian,

Quick q: how is a protostream marshaller supposed to deal with optional fields?

I don't see any writer methods that deal with those... is it up to the user to put something on the wire to decide at read time whether the optional field follows or not?

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



From anistor at redhat.com  Tue Oct 24 07:43:38 2017
From: anistor at redhat.com (Adrian Nistor)
Date: Tue, 24 Oct 2017 14:43:38 +0300
Subject: [infinispan-dev] Protostream marshaller support for optional
	fields
In-Reply-To: <3B213514-D2DF-4B1D-82E2-BA9C5445AA43@redhat.com>
References: <3B213514-D2DF-4B1D-82E2-BA9C5445AA43@redhat.com>
Message-ID: <4f3bce55-4663-f885-8aeb-d11adab80a0e@redhat.com>

Hi Galder,

There's nothing special about optional fields. It is the required fields 
that are special: they do not allow null (in the read/write methods).

If a field is optional in your protobuf schema you can write a null 
value and protostream will happily interpret that as a missing value and 
will not write any tag in the output protobuf stream.
Reading a missing value will return a null. The required/optional status 
of a field is checked against the schema at runtime, so you cannot cheat :).

None of the above holds true for a required field. Writes will only 
accept non-nulls (an exception is thrown immediately). Reads will always 
return a non-null value, so you can safely use a 
primitive-type-returning read method. If the input stream does not 
contain a required field (probably because the encoder that produced it 
was violating the schema) an exception is thrown.

Adrian

On 10/23/2017 06:51 PM, Galder Zamarre?o wrote:
> Hey Adrian,
>
> Quick q: how is a protostream marshaller supposed to deal with optional fields?
>
> I don't see any writer methods that deal with those... is it up to the user to put something on the wire to decide at read time whether the optional field follows or not?
>
> Cheers,
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>


From rory.odonnell at oracle.com  Fri Oct 27 04:47:27 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 27 Oct 2017 09:47:27 +0100
Subject: [infinispan-dev] JDK 8u162 b01 Early Access is available on
	jdk.java.net
Message-ID: <178ee9b7-3f7c-2293-5534-9aa2796e739a@oracle.com>

Hi Galder,

*JDK 8u162 Early Access*? build 01 is available at : - jdk.java.net/8/ 
<http://jdk.java.net/8/>

Information and schedules specific to OpenJDK 8u162 release are listed 
here <http://openjdk.java.net/projects/jdk8u/releases/8u162.html>


<http://openjdk.java.net/projects/jdk8u/releases/8u162.html>

*JRE and JDK Cryptographic Roadmap* has been updated the details are 
here <https://www.java.com/en/jre-jdk-cryptoroadmap.html>

**

*JavaOne2017* took place October 1 to 5, 2017 at San Francisco.

If you were unable to attend the event or missed some talks, below you 
will find links to keynotes from last week
that have been posted for on-demand replay:

  * JavaOne Opening Keynote (Monday, Oct. 2):
      o https://www.oracle.com/javaone/on-demand.html?bcid=5596229112001
  * Oracle Code Keynote (Tuesday, Oct. 3):
      o https://www.oracle.com/javaone/on-demand.html?bcid=5600354378001
  * JavaOne Community Keynote (Thursday, Oct. 5):
      o https://www.oracle.com/javaone/on-demand.html?bcid=5604479599001


Regards,
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/20171027/c1c65788/attachment.html 

From galder at redhat.com  Fri Oct 27 08:00:22 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Fri, 27 Oct 2017 14:00:22 +0200
Subject: [infinispan-dev] Protostream marshaller support for optional
	fields
In-Reply-To: <4f3bce55-4663-f885-8aeb-d11adab80a0e@redhat.com>
References: <3B213514-D2DF-4B1D-82E2-BA9C5445AA43@redhat.com>
	<4f3bce55-4663-f885-8aeb-d11adab80a0e@redhat.com>
Message-ID: <8E940BD5-6ABF-407C-AD7D-C530B91DDB10@redhat.com>

Ok, thanks for the clarification.

> On 24 Oct 2017, at 13:43, Adrian Nistor <anistor at redhat.com> wrote:
> 
> Hi Galder,
> 
> There's nothing special about optional fields. It is the required fields that are special: they do not allow null (in the read/write methods).
> 
> If a field is optional in your protobuf schema you can write a null value and protostream will happily interpret that as a missing value and will not write any tag in the output protobuf stream.
> Reading a missing value will return a null. The required/optional status of a field is checked against the schema at runtime, so you cannot cheat :).
> 
> None of the above holds true for a required field. Writes will only accept non-nulls (an exception is thrown immediately). Reads will always return a non-null value, so you can safely use a primitive-type-returning read method. If the input stream does not contain a required field (probably because the encoder that produced it was violating the schema) an exception is thrown.
> 
> Adrian
> 
> On 10/23/2017 06:51 PM, Galder Zamarre?o wrote:
>> Hey Adrian,
>> 
>> Quick q: how is a protostream marshaller supposed to deal with optional fields?
>> 
>> I don't see any writer methods that deal with those... is it up to the user to put something on the wire to decide at read time whether the optional field follows or not?
>> 
>> Cheers,
>> --
>> Galder Zamarre?o
>> Infinispan, Red Hat
>> 
> 

--
Galder Zamarre?o
Infinispan, Red Hat



From mudokonman at gmail.com  Fri Oct 27 14:09:10 2017
From: mudokonman at gmail.com (William Burns)
Date: Fri, 27 Oct 2017 18:09:10 +0000
Subject: [infinispan-dev] Infinispan 9.2.0.Alpha2 & 9.1.2.Final have been
	releasesd
Message-ID: <CA+YCuUP6Pu9WrgaFSaAvtL0h8T1R=yQujTUgCMqbipOz5iozXg@mail.gmail.com>

Hey everyone,

Our second release of Infinispan 9.2 is now available as well as the latest
of our stable branch 9.1. Read more about these at
*http://blog.infinispan.org/2017/10/infinispan-920alpha2-912final-released.html
<http://blog.infinispan.org/2017/10/infinispan-920alpha2-912final-released.html>*

Enjoy,

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

From galder at redhat.com  Mon Oct 30 04:49:34 2017
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 30 Oct 2017 09:49:34 +0100
Subject: [infinispan-dev] Initial Infinispan driver for JNoSQL
In-Reply-To: <7a8be28e-ab4c-5796-3cbc-ad337ce8e7ef@redhat.com>
References: <7a8be28e-ab4c-5796-3cbc-ad337ce8e7ef@redhat.com>
Message-ID: <F0B462CB-53BB-4588-911D-D0826047E284@redhat.com>

Hey Tristan,

Thanks for submitting that.

Why did you decide to mix embedded and remote in same project?

Cheers,

> On 19 Oct 2017, at 16:05, Tristan Tarrant <ttarrant at redhat.com> wrote:
> 
> Hi all,
> 
> I have just submitted a pull request for an initial driver for JNoSQL
> 
> https://github.com/eclipse/jnosql-diana-driver/pull/49
> 
> Tristan
> -- 
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarre?o
Infinispan, Red Hat



From slaskawi at redhat.com  Mon Oct 30 08:31:49 2017
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 30 Oct 2017 12:31:49 +0000
Subject: [infinispan-dev] KUBE_PING 1.0.5.Final released
Message-ID: <CAA9R9O7fDPyA3OhbepFep4YnCw35qNUDRBerUFtohds_6c6y_Q@mail.gmail.com>

Hey,

I'm happy to announce that KUBE_PING v. 1.0.5.Final has just been released.
The version includes:

   - Fixed memory leak
   - Split clusters during upgrade
   - HTTPS is now the default protocol

As you may have noticed I skipped some versions in between. It turned out
that some version were already released without any announcement [1]. My
intuition tells me that this happened by mistake (and Maven Staging Plugin
just closes and releases staging repository [2]). Please be careful with
this plugin in the future.

More information about the release might be found here:
https://github.com/jgroups-extras/jgroups-kubernetes/releases/tag/jgroups-kubernetes-1.0.5.Final

Thanks,
Sebastian

[1]
https://origin-repository.jboss.org/nexus/content/repositories/public-jboss/org/jgroups/kubernetes/jgroups-kubernetes/
like 1.0.1.Final or 1.0.3.Final.
[2]
https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/pom.xml#L168
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171030/ffb1ee3d/attachment.html 

From ttarrant at redhat.com  Mon Oct 30 11:55:53 2017
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 30 Oct 2017 16:55:53 +0100
Subject: [infinispan-dev] Weekly IRC Meeting logs 2017-10-30
Message-ID: <878d2bd8-293d-7595-28c4-d6fe8cec66f2@redhat.com>

Dear all,
the weekly meeting logs are available at

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

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