From rvansa at redhat.com  Wed Apr  1 03:42:00 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 01 Apr 2015 09:42:00 +0200
Subject: [infinispan-dev] Multi get API
In-Reply-To: <CAFm4XO3m44fp_81352QzdZnYukBj_iCQ_2pi-aoH4Sjjsr8RWg@mail.gmail.com>
References: <CA+YCuUNfr8Lgh4yb+7BQhOVSGHNeSvkWBg5Xyp80f-TdUgaqqA@mail.gmail.com>	<9E0BA454-9A6F-4E51-BDCD-AA8392ABF987@redhat.com>	<5513D990.7000600@redhat.com>	<CAFm4XO1=MNLpf+u6OMZX0Y5_1T6q=j1_3fFehOSazxNHAfnXMg@mail.gmail.com>	<CA+YCuUMmL=jrk-SD5JFhdChrJ=0oA64QA8ftbaqb5K0BfMdB1A@mail.gmail.com>	<CAFm4XO2zT2Q=qzxqhyvYsbmBYLFpGb5ePx7eyqHdSrL9+t1R0w@mail.gmail.com>	<55141BC0.1050303@redhat.com>	<DBCC89B2-D5ED-4B92-B993-76D4D77697AA@redhat.com>
	<CAFm4XO3m44fp_81352QzdZnYukBj_iCQ_2pi-aoH4Sjjsr8RWg@mail.gmail.com>
Message-ID: <551BA148.1040700@redhat.com>

On 03/31/2015 08:41 PM, Sanne Grinovero wrote:
> On 31 March 2015 at 16:25, Galder Zamarre?o <galder at redhat.com> wrote:
>>> On 26 Mar 2015, at 15:46, Radim Vansa <rvansa at redhat.com> wrote:
>>>
>>> On 03/26/2015 03:00 PM, Sanne Grinovero wrote:
>>>> On 26 March 2015 at 13:43, William Burns <mudokonman at gmail.com> wrote:
>>>>> On Thu, Mar 26, 2015 at 8:50 AM, Sanne Grinovero <sanne at infinispan.org> wrote:
>>>>>> In terms of naming, I'd prefer _getMulti_.
>>>>>> My reasoning is it's nice if has a common prefix with _get_ as that
>>>>>> helps someone exploring the API from an IDE, giving better assistance
>>>>>> to people learning.
>>>>>>
>>>>>> getAll is misleading, as is getMany or get getAllOf as they imply I'm
>>>>>> searching for something based on a pattern but you're expecting the
>>>>>> keys and returning tuples key/value.
>>>>> I can understand your point, however since JCache already defined this
>>>>> as getAll I can't see but using that name.
>>>> Ok that makes it win a bit of points, and at least it starts with _get_.
>>> Was there any discussion regarding this during JSR-107 development? I
>>> wonder why have they chosen such misleading name. Galder?
>> Dunno, never saw it discussed, but I supposed they chose that name cos of Map.putAll
>>
>> I think it's the wrong name, getMany, getMulti are better IMO, regardless of what JCache/java.util.Map do.
>>
>> Also, see what they did with CacheWriter and CacheLoader, they're no symmetrical... and we followed the same pattern in our persistence :|
> My initial assumption was that we'd use a varargs parameter to list
> the keys to be fetched; in that case getAll() could have been invoked
> with zero parameters, and it would look like as it should return all
> entries of the grid.

Varargs could look nice, I wonder how much would the API bloat if we had 
both options. Though, it would be even better if we could force at least 
two arguments in the varargs API to prevent obvious mistakes as 
argument-less version or even trying to call it with Set<Object> but 
(e.g. due to refactoring) falling back to the vararg version. However, 
if we had getAll(Object o1, Object o2, Object... otherObjects), it would 
prohibit us from simply wrapping the varargs array into Set (for further 
processing), we would have to allocate another array.
In the end, just Set is probably better :) For varargs version, we can 
provide CollectionFactory.makeSet(T... objects) and recommend this in 
examples in documentation, since there's no appropriate method in Arrays 
nor in Collections.

I am still reluctant to the getAll() name. addAll and putAll insert all 
elements I am passing, while getAll suggests retrieval of all obejcts in 
the collection.  On the other hand, after looking into competitors' API, 
Coherence and EhCache use getAll(Collection), Hazelcast uses 
getAll(Set), so users can live with getAll.


>
> I guess having now a Set for the keys makes the getAll() not too bad.
>
> @William +1 to not implement the future-like behaviour (lazy loaded
> HashMap) in the first step. I wasn't asking for that, just thinking
> ahead about the merits of returning such a type.

I forgot to react on this - making the Map<K, V> lazy underneath is 
maybe obscuring the perf consequences from the user; he could expect 
that everything is local=fast after the getAll request returns. If we're 
going to have a lazy-loading map, it should rather look like Map<K, 
xxxFuture<V> >.

Radim

>
> Sanne
>
>>>>
>>>>>> I like the idea of returning a Map, as you can actually make the map
>>>>>> behave like a Future: the Map instance could be returned right away,
>>>>>> but retrieving of some entries would be blocking until they are
>>>>>> retrieved. You wouldn't need to block on having all entries, just the
>>>>>> ones being actively asked for. In other words, it's better than
>>>>>> returning a Future<Map>.
>>>>>> This should invalidate some of the previous concerns about using Map ?
>>>>> I had thought about this briefly, but didn't give it much though since
>>>>> it makes things quite complicated (interceptor stack and tx context I
>>>>> am looking at you).  I would say to do this later if we wanted, since
>>>>> the API doesn't have to be different (other than the fact that people
>>>>> should start possibly expecting CacheExceptions from calling Map.get
>>>>> and other methods).
>>>>>
>>>>>> @William I didn't understand your concern on upper and lower bounds.
>>>>>> The returned types should be coupled to the Cache types; being able to
>>>>> The return type is coupled to the Cache types, this was about the
>>>>> input type defined on the Set.
>>>>>
>>>>>> pass Object might be nice but let's make sure no casting is required
>>>>>> on the client? Could you make some examples of your alternative
>>>>>> proposal?
>>>>> With Set<?> the client would never have to do any casting.
>>>> I'm confused. Not sure which Set you're talking about. And remember
>>>> that if you're being very liberal with the promise of returned types,
>>>> how is the implementation going to handle the guarantee?
>>>>
>>>> For example, what's going to happen if the requested objects don't
>>>> match the user expected type? The API shouldn't make promises it can't
>>>> maintain.
>>> The cache.get(k1) should return object stored under key k2 such that
>>>
>>> k1.hashCode() == k2.hashCode() && k1.equals(k2)
>>>
>>> Nothing is said about k1's type (though, Object.equals() states that
>>> equals should always form symmetric relation).
>>> The contract was once set for all java collections, let's stick to that.
>>>
>>> Radim
>>>
>>>> Thanks,
>>>> Sanne
>>>>
>>>>>> On 26 March 2015 at 10:04, Radim Vansa <rvansa at redhat.com> wrote:
>>>>>>> On 03/26/2015 10:28 AM, Galder Zamarre?o wrote:
>>>>>>>> Comments inline:
>>>>>>>>
>>>>>>>>> On 24 Mar 2015, at 14:22, William Burns <mudokonman at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I am nearing completion of the new multi get command [1], allowing for
>>>>>>>>> more efficient retrieval of multiple keys at the same time.  Thanks
>>>>>>>>> again to Radim for a lot of the initial work.
>>>>>>>>>
>>>>>>>>> In doing so though I want to make sure I get feedback on how we want
>>>>>>>>> the API to actually look, since this is much more difficult to change
>>>>>>>>> down the line.
>>>>>>>>>
>>>>>>>>> There are a few things in particular I wanted to discuss.
>>>>>>>>>
>>>>>>>>> 1. The actual name of the method.  The main suggestions I have seen
>>>>>>>>> are getAll or getMany.  I do like the naming of the former, however it
>>>>>>>>> seems a bit misleading (remember API is getAll(Set) since we are
>>>>>>>>> really getting a subset.  So I am thinking the possibilities at this
>>>>>>>>> point are getAllOf, getAllFor or getMany.  I am leaning maybe towards
>>>>>>>>> the last one (getMany).  I am open to any suggestions though.
>>>>>>>> JSR-107 has getAll(Set), which I think it's a bit confusing too naming wise.
>>>>>>>>
>>>>>>>> getMany or getAllOf sound better to me.
>>>>>>>>
>>>>>>>>> 2. What should the return value be for this method.  Currently this
>>>>>>>>> returns a Map<K, V> which makes sense when we retain these values in
>>>>>>>>> the local transactional context and is pretty nice and clean for end
>>>>>>>>> users.
>>>>>>>>>
>>>>>>>>> The other idea is to use a streaming API possibly returning an
>>>>>>>>> Iterable<CacheEntry<K, V>>.  The streaming return value doesn't seem
>>>>>>>>> as intuitive to me, but opens us up for more efficient usage
>>>>>>>>> especially when there may be a lot of keys passed in (also results can
>>>>>>>>> be processed concurrently while retrieval is still occurring).
>>>>>>>>>
>>>>>>>>> I would lean towards returning the Map<K, V> value, however the next
>>>>>>>>> point could change that.
>>>>>>>>>
>>>>>>>>> 3. Where this method should live.  Right now this method is on the
>>>>>>>>> BasicCache interface which is a parent of both Cache (embedded) and
>>>>>>>>> RemoteCache (remote).  Unfortunately for remote clients to be as
>>>>>>>>> efficient as possible we really need a Streaming API so that we don't
>>>>>>>>> have multiple copies of data in memory at multiple places at the same
>>>>>>>>> time.  For that reason I suggest we use the streaminig API for both or
>>>>>>>>> have a different API for remote vs embedded.
>>>>>>>> Hmmm, I've been thinking about the same thing for Java 8 API (see the proposal wiki), and I think returning a Map limits things. On Java 8, I'm considering switching `evalAll` from returning a Map of CompletableFutures to a Stream... More to come next week.
>>>>>>>>
>>>>>>>> Now, for the current version, I think Map is limiting for both remote and embedded, because even for embedded, retrieving an entry might be a remote operation, so that forces you to wait for all of the entries to be available before you can return the map. Same thing for Remote.
>>>>>>>>
>>>>>>>> What about returning an Iterator? That could be lazy and more suited for the use case? If you need to return a Map, e.g. to implement JCache.getAll(), you can wait for all and construct a map.
>>>>>>> What's the expected usecase? I would expect that users want to just
>>>>>>> retrieve few keys at once, without any fancy lazy
>>>>>>> wait-for-completion-and-do-after stuff. Just imagine that you want to
>>>>>>> pass the two values into another method, Iterator/Stream API wouldn't
>>>>>>> help you with that much.
>>>>>>>
>>>>>>> It seems to me that it is very useful to have multi get with Map<K, V>
>>>>>>> as return type in the API - we don't want to force constructs like:
>>>>>>>
>>>>>>> Iterator<Map.Entry<K, V>> it = cache.multiGet(key1, key2, key3);
>>>>>>> for (; it.hasNext();) {
>>>>>>>       Map.Entry<K, V> entry = it.next();
>>>>>>>       if (entry.getKey().equals(key1)) value1 = entry.getValue();
>>>>>>>       else if (entry.getKey().equals(key2)) value2 = entry.getValue();
>>>>>>>       else if (entry.getKey().equals(key3)) value3 = entry.getValue();
>>>>>>> }
>>>>>>>
>>>>>>> or let them flip it into the map manually (HashMap does not have
>>>>>>> constructor accepting iterator)
>>>>>>>
>>>>>>> Iterator<Map.Entry<K, V>> it = cache.multiGet(key1, key2, key3);
>>>>>>> Map<K, V> map = new HashMap<>();
>>>>>>> for (; it.hasNext();) {
>>>>>>>       Map.Entry<K, V> entry = it.next();
>>>>>>>       map.put(entry.getKey(), entry.getValue());
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>> Now, whether to have a separate API for this, since we have Java 8 API coming up, I'd not worry too much at this point.
>>>>>>> It seems to me that with 8, we're going to have complicated lazy
>>>>>>> omnipotent API, and several facades simplifying that into Map, JCache or
>>>>>>> whatever. So, let's provide the simplistic API with Map now, and the
>>>>>>> lazy versions can get into the lazy API as soon as we'll see how the
>>>>>>> other methods will look like.
>>>>>>>
>>>>>>> Radim
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>>> Let me know what you guys think.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> - Will
>>>>>>>>>
>>>>>>>>> [1] https://issues.jboss.org/browse/ISPN-2183
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>> --
>>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> 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
>>
>> --
>> 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


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


From ales.justin at gmail.com  Thu Apr  2 11:33:26 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Thu, 2 Apr 2015 17:33:26 +0200
Subject: [infinispan-dev] tests deadlock
Message-ID: <F4A26335-ECE3-4041-B772-1BCEB1257451@gmail.com>

I'm trying to add and run a test
* https://gist.github.com/alesj/f2b48b3697a6252777f4 <https://gist.github.com/alesj/f2b48b3697a6252777f4>

Yet it never finishes ...
* https://gist.github.com/alesj/ea912570bc72cb4073f9 <https://gist.github.com/alesj/ea912570bc72cb4073f9>

My branch
* https://github.com/alesj/infinispan/tree/projections <https://github.com/alesj/infinispan/tree/projections>

Any idea?

-Ales

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

From tsykora at redhat.com  Fri Apr  3 01:41:59 2015
From: tsykora at redhat.com (Tomas Sykora)
Date: Fri, 3 Apr 2015 01:41:59 -0400 (EDT)
Subject: [infinispan-dev] JBoss R&D Laboratory in Brno | 2 Infinispan
	related projects
In-Reply-To: <336182990.12141192.1428039045683.JavaMail.zimbra@redhat.com>
Message-ID: <1799230079.12150289.1428039719243.JavaMail.zimbra@redhat.com>

Hello Infinispan community,

I'm bringing good news for us. Currently, we are starting JBoss R&D Laboratory at Faculty of Informatics (Masaryk University, Brno). We are hoping that our initiative will bring new contributors to Infinispan projects -- mainly students from local Universities. 

You can learn more about the LAB and project proposals at: https://developer.jboss.org/wiki/JBossRDLabAtFIMUNI

If you have ANY ideas, proposals, concerns or just comments -- share them please.

I will keep you informed!
Tomas

From dan.berindei at gmail.com  Fri Apr  3 06:55:57 2015
From: dan.berindei at gmail.com (Dan Berindei)
Date: Fri, 3 Apr 2015 13:55:57 +0300
Subject: [infinispan-dev] tests deadlock
In-Reply-To: <F4A26335-ECE3-4041-B772-1BCEB1257451@gmail.com>
References: <F4A26335-ECE3-4041-B772-1BCEB1257451@gmail.com>
Message-ID: <CA+nfvwQN-xomMwPBpYsPROpw_T+bdPnM72RAB7i_5s=dre9CdA@mail.gmail.com>

Should be fixed by https://github.com/infinispan/infinispan/pull/3359

Dan


On Thu, Apr 2, 2015 at 6:33 PM, Ales Justin <ales.justin at gmail.com> wrote:
> I'm trying to add and run a test
> * https://gist.github.com/alesj/f2b48b3697a6252777f4
>
> Yet it never finishes ...
> * https://gist.github.com/alesj/ea912570bc72cb4073f9
>
> My branch
> * https://github.com/alesj/infinispan/tree/projections
>
> Any idea?
>
> -Ales
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From pedro at infinispan.org  Mon Apr  6 09:28:48 2015
From: pedro at infinispan.org (Pedro Ruivo)
Date: Mon, 06 Apr 2015 14:28:48 +0100
Subject: [infinispan-dev] Relaxing clear semantics
Message-ID: <55228A10.2000009@infinispan.org>

Hi guys,

I'm going to start working on the new relaxed clear semantic (in the 
context of ISPN-4140). It affects, at least, the following JIRA:

ISPN-4073: clear() can create inconsistencies
ISPN-3656: Relax Cache.clear() semantics
ISPN-4778: PessimisticLockingInterceptor throws when handling remote 
clear command
ISPN-4140: Clear command doesn't acquire any remote locks in pessimistic 
mode
ISPN-2849: Don't keep threads blocked when waiting for locks to be released

In short, the semantic would be: "it clears the cache. If any concurrent 
operation is in progress, the result is undetermined".
So, if concurrent operation can put the cache in inconsistent state. But 
in other hand, I don't see any case in which a clear is needed during 
production...

In transactional cache, the clear will not affect the transaction. Also, 
it will not acquire any locks in LockManager. Why?
First, we assume that no other operation is in progress, second, if the 
first assumption is wrong, it can cause deadlocks with it, and third, it 
would avoid creating a global lock.

Any other concerns?

Cheers,
Pedro

From pierre.sutra at unine.ch  Tue Apr  7 12:46:28 2015
From: pierre.sutra at unine.ch (Pierre Sutra)
Date: Tue, 7 Apr 2015 18:46:28 +0200
Subject: [infinispan-dev] Eventing mechanism and ordering
Message-ID: <552409E4.303@unine.ch>

Hello,

I have run some tests regarding the ordering properties of the clustered
eventing mechanism in Infinispan
(https://gist.github.com/otrack/0b67dcdae61bb83e0da3).

When transaction are set to false, clustered listeners receive events in
the same order, as expected. Yet, this is not the case when transactions
are available. I would like to know whether this behavior is expected,
or not, as the documentation does not precise it.

Cheers,
Pierre


From mudokonman at gmail.com  Tue Apr  7 16:15:58 2015
From: mudokonman at gmail.com (William Burns)
Date: Tue, 7 Apr 2015 16:15:58 -0400
Subject: [infinispan-dev] Eventing mechanism and ordering
In-Reply-To: <552409E4.303@unine.ch>
References: <552409E4.303@unine.ch>
Message-ID: <CA+YCuUMDW9z37FSfrV6o8wMnL+mbBwFCMv0BxE_4NHn0C19Mxw@mail.gmail.com>

I ran the test a bit locally.  It seems the ordering is fine either
way, however when transactions are enabled sometimes an event is
raised twice (I only ever saw a mismatch in size).  I tweaked the test
to use regular listeners as well and it happens there as well.  I
would say to log a JIRA and we can look further into it.
]


On Tue, Apr 7, 2015 at 12:46 PM, Pierre Sutra <pierre.sutra at unine.ch> wrote:
> Hello,
>
> I have run some tests regarding the ordering properties of the clustered
> eventing mechanism in Infinispan
> (https://gist.github.com/otrack/0b67dcdae61bb83e0da3).
>
> When transaction are set to false, clustered listeners receive events in
> the same order, as expected. Yet, this is not the case when transactions
> are available. I would like to know whether this behavior is expected,
> or not, as the documentation does not precise it.
>
> Cheers,
> Pierre
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From sebastian.laskawiec at gmail.com  Thu Apr  9 09:03:04 2015
From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=)
Date: Thu, 09 Apr 2015 13:03:04 +0000
Subject: [infinispan-dev] Quickstarts consolidation
Message-ID: <CADP5VTWR9pzSvhqLeGfKPb0536_e-UcOpCx+a+trLXs=op+4hw@mail.gmail.com>

Hey!

I'm working on consolidating quickstarts [1] and I would like to ask for
your opinion.

Currently we have 2 quickstarts repositories - jboss-jdg-quickstarts [2]
and infinispan-quickstart [3]. I think the latter repository is redundant
and can be closed. There are at least 2 arguments for it - Infinispan web
page points to the jboss-jdg-quickstarts repo [4] and all relevant
quickstarts have been already migrated.

What do you think?

Thanks
Sebastian

[1] https://issues.jboss.org/browse/ISPN-3654
[2] https://github.com/jboss-developer/jboss-jdg-quickstarts
[3] https://github.com/infinispan/infinispan-quickstart
[4] http://infinispan.org/quickstarts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150409/a895d12a/attachment.html 

From jholusa at redhat.com  Thu Apr  9 09:35:26 2015
From: jholusa at redhat.com (Jiri Holusa)
Date: Thu, 9 Apr 2015 09:35:26 -0400 (EDT)
Subject: [infinispan-dev] Quickstarts consolidation
In-Reply-To: <CADP5VTWR9pzSvhqLeGfKPb0536_e-UcOpCx+a+trLXs=op+4hw@mail.gmail.com>
References: <CADP5VTWR9pzSvhqLeGfKPb0536_e-UcOpCx+a+trLXs=op+4hw@mail.gmail.com>
Message-ID: <1069697252.11451695.1428586526242.JavaMail.zimbra@redhat.com>

This is a great idea, absolutely +1.

----- Original Message -----
From: "Sebastian ?askawiec" <sebastian.laskawiec at gmail.com>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Sent: Thursday, April 9, 2015 3:03:04 PM
Subject: [infinispan-dev] Quickstarts consolidation

Hey! 

I'm working on consolidating quickstarts [1] and I would like to ask for your opinion. 

Currently we have 2 quickstarts repositories - jboss-jdg-quickstarts [2] and infinispan-quickstart [3]. I think the latter repository is redundant and can be closed. There are at least 2 arguments for it - Infinispan web page points to the jboss-jdg-quickstarts repo [4] and all relevant quickstarts have been already migrated. 

What do you think? 

Thanks 
Sebastian 

[1] https://issues.jboss.org/browse/ISPN-3654 
[2] https://github.com/jboss-developer/jboss-jdg-quickstarts 
[3] https://github.com/infinispan/infinispan-quickstart 
[4] http://infinispan.org/quickstarts/ 

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


From vchepeli at redhat.com  Thu Apr  9 12:45:39 2015
From: vchepeli at redhat.com (Vitalii Chepeliuk)
Date: Thu, 09 Apr 2015 18:45:39 +0200
Subject: [infinispan-dev] Quickstarts consolidation
In-Reply-To: <CADP5VTWR9pzSvhqLeGfKPb0536_e-UcOpCx+a+trLXs=op+4hw@mail.gmail.com>
References: <CADP5VTWR9pzSvhqLeGfKPb0536_e-UcOpCx+a+trLXs=op+4hw@mail.gmail.com>
Message-ID: <1428597939.8028.0.camel@redhat.com>

+1 from me

Vitalii

On Thu, 2015-04-09 at 13:03 +0000, Sebastian ?askawiec wrote:
> Hey!
> 
> 
> I'm working on consolidating quickstarts [1] and I would like to ask
> for your opinion.
> 
> 
> Currently we have 2 quickstarts repositories - jboss-jdg-quickstarts
> [2] and infinispan-quickstart [3]. I think the latter repository is
> redundant and can be closed. There are at least 2 arguments for it -
> Infinispan web page points to the jboss-jdg-quickstarts repo [4] and
> all relevant quickstarts have been already migrated.
> 
> 
> What do you think?
> 
> 
> Thanks
> Sebastian
> 
> 
> [1] https://issues.jboss.org/browse/ISPN-3654
> [2] https://github.com/jboss-developer/jboss-jdg-quickstarts
> [3] https://github.com/infinispan/infinispan-quickstart
> [4] http://infinispan.org/quickstarts/
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From galder at redhat.com  Fri Apr 10 02:58:14 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Fri, 10 Apr 2015 08:58:14 +0200
Subject: [infinispan-dev] ISPN-5085 needs a Wildfly 8.2.0 upgrade...
Message-ID: <8B80B9BE-57DE-43C7-804D-F58D199D1F34@redhat.com>

Hey,

Re: https://issues.jboss.org/browse/ISPN-5085

Resteasy version in Wildfly 8.1.0 is 3.0.8 which has a bug inside the Netty integration when dealing with empty responses.

The issue is fixed in 3.0.10, which is included in Wildly 8.2.0

We tried to rebase onto Widlfly 8.2.0 but we had some issues with CDI [1].

What should we do?

If upgrade not possible, do we add Resteasy 3.0.10 as module and depend on that instead?

Cheers,

[1] https://github.com/infinispan/infinispan/pull/3216
[2] https://issues.jboss.org/browse/WFLY-4250
--
Galder Zamarre?o
galder at redhat.com






From sanne at infinispan.org  Fri Apr 10 07:46:53 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Fri, 10 Apr 2015 13:46:53 +0200
Subject: [infinispan-dev] ISPN-5085 needs a Wildfly 8.2.0 upgrade...
In-Reply-To: <8B80B9BE-57DE-43C7-804D-F58D199D1F34@redhat.com>
References: <8B80B9BE-57DE-43C7-804D-F58D199D1F34@redhat.com>
Message-ID: <CAFm4XO2RhjW2SxGGZPNJoG1DC4nFqazJEE-_VPSDii67DT+APQ@mail.gmail.com>

I would suggest basing on WildFly 9

On 10 April 2015 at 08:58, Galder Zamarre?o <galder at redhat.com> wrote:
> Hey,
>
> Re: https://issues.jboss.org/browse/ISPN-5085
>
> Resteasy version in Wildfly 8.1.0 is 3.0.8 which has a bug inside the Netty integration when dealing with empty responses.
>
> The issue is fixed in 3.0.10, which is included in Wildly 8.2.0
>
> We tried to rebase onto Widlfly 8.2.0 but we had some issues with CDI [1].
>
> What should we do?
>
> If upgrade not possible, do we add Resteasy 3.0.10 as module and depend on that instead?
>
> Cheers,
>
> [1] https://github.com/infinispan/infinispan/pull/3216
> [2] https://issues.jboss.org/browse/WFLY-4250
> --
> 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 Apr 10 11:16:12 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Fri, 10 Apr 2015 17:16:12 +0200
Subject: [infinispan-dev] JBoss R&D Laboratory in Brno | 2 Infinispan
	related projects
In-Reply-To: <1799230079.12150289.1428039719243.JavaMail.zimbra@redhat.com>
References: <1799230079.12150289.1428039719243.JavaMail.zimbra@redhat.com>
Message-ID: <269EE257-5477-475C-9044-595F4586767B@redhat.com>

Hey Tomas, this is really cool and we're delighted to see Infinispan projects represented there!

> On 3 Apr 2015, at 07:41, Tomas Sykora <tsykora at redhat.com> wrote:
> 
> Hello Infinispan community,
> 
> I'm bringing good news for us. Currently, we are starting JBoss R&D Laboratory at Faculty of Informatics (Masaryk University, Brno). We are hoping that our initiative will bring new contributors to Infinispan projects -- mainly students from local Universities. 
> 
> You can learn more about the LAB and project proposals at: https://developer.jboss.org/wiki/JBossRDLabAtFIMUNI
> 
> If you have ANY ideas, proposals, concerns or just comments -- share them please.
> 
> I will keep you informed!
> Tomas
> _______________________________________________
> 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  Fri Apr 10 12:22:19 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Fri, 10 Apr 2015 18:22:19 +0200
Subject: [infinispan-dev] Quickstarts consolidation
In-Reply-To: <CADP5VTWR9pzSvhqLeGfKPb0536_e-UcOpCx+a+trLXs=op+4hw@mail.gmail.com>
References: <CADP5VTWR9pzSvhqLeGfKPb0536_e-UcOpCx+a+trLXs=op+4hw@mail.gmail.com>
Message-ID: <25EC0BA2-4ADA-4AD4-B221-EDEC854138FB@redhat.com>

Hey Sebastian,

I like the idea but hat about jboss-as7 and jcache quickstarts in [3] ? Where are those in [2]?

Cheers,

> On 9 Apr 2015, at 15:03, Sebastian ?askawiec <sebastian.laskawiec at gmail.com> wrote:
> 
> Hey!
> 
> I'm working on consolidating quickstarts [1] and I would like to ask for your opinion.
> 
> Currently we have 2 quickstarts repositories - jboss-jdg-quickstarts [2] and infinispan-quickstart [3]. I think the latter repository is redundant and can be closed. There are at least 2 arguments for it - Infinispan web page points to the jboss-jdg-quickstarts repo [4] and all relevant quickstarts have been already migrated.
> 
> What do you think?
> 
> Thanks
> Sebastian
> 
> [1] https://issues.jboss.org/browse/ISPN-3654
> [2] https://github.com/jboss-developer/jboss-jdg-quickstarts
> [3] https://github.com/infinispan/infinispan-quickstart
> [4] http://infinispan.org/quickstarts/
> _______________________________________________
> 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  Fri Apr 10 12:24:34 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Fri, 10 Apr 2015 18:24:34 +0200
Subject: [infinispan-dev] ISPN-5085 needs a Wildfly 8.2.0 upgrade...
In-Reply-To: <CAFm4XO2RhjW2SxGGZPNJoG1DC4nFqazJEE-_VPSDii67DT+APQ@mail.gmail.com>
References: <8B80B9BE-57DE-43C7-804D-F58D199D1F34@redhat.com>
	<CAFm4XO2RhjW2SxGGZPNJoG1DC4nFqazJEE-_VPSDii67DT+APQ@mail.gmail.com>
Message-ID: <69B39629-2E84-4EFA-B1C5-A2D8819A4A60@redhat.com>


> On 10 Apr 2015, at 13:46, Sanne Grinovero <sanne at infinispan.org> wrote:
> 
> I would suggest basing on WildFly 9

I tried that but doing it is quite a task at this stage in the 7.2 release [3].

I'll try to use a newer library version and see if that works with current set up.

Cheers,

[3] https://issues.jboss.org/browse/ISPN-5009

> 
> On 10 April 2015 at 08:58, Galder Zamarre?o <galder at redhat.com> wrote:
>> Hey,
>> 
>> Re: https://issues.jboss.org/browse/ISPN-5085
>> 
>> Resteasy version in Wildfly 8.1.0 is 3.0.8 which has a bug inside the Netty integration when dealing with empty responses.
>> 
>> The issue is fixed in 3.0.10, which is included in Wildly 8.2.0
>> 
>> We tried to rebase onto Widlfly 8.2.0 but we had some issues with CDI [1].
>> 
>> What should we do?
>> 
>> If upgrade not possible, do we add Resteasy 3.0.10 as module and depend on that instead?
>> 
>> Cheers,
>> 
>> [1] https://github.com/infinispan/infinispan/pull/3216
>> [2] https://issues.jboss.org/browse/WFLY-4250
>> --
>> 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 ttarrant at redhat.com  Fri Apr 10 15:26:59 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Fri, 10 Apr 2015 21:26:59 +0200
Subject: [infinispan-dev] ISPN-5085 needs a Wildfly 8.2.0 upgrade...
In-Reply-To: <CAFm4XO2RhjW2SxGGZPNJoG1DC4nFqazJEE-_VPSDii67DT+APQ@mail.gmail.com>
References: <8B80B9BE-57DE-43C7-804D-F58D199D1F34@redhat.com>
	<CAFm4XO2RhjW2SxGGZPNJoG1DC4nFqazJEE-_VPSDii67DT+APQ@mail.gmail.com>
Message-ID: <55282403.9010400@redhat.com>

No, the plan is to base on WildFly Core. But we cannot do that during 
the 7.x cycle, so this will have to wait for 8.0. In the meantime, we 
can still base on 8.1 upgrading the single resteasy module to the 
version we need.

Tristan

On 10/04/2015 13:46, Sanne Grinovero wrote:
> I would suggest basing on WildFly 9
>
> On 10 April 2015 at 08:58, Galder Zamarre?o <galder at redhat.com> wrote:
>> Hey,
>>
>> Re: https://issues.jboss.org/browse/ISPN-5085
>>
>> Resteasy version in Wildfly 8.1.0 is 3.0.8 which has a bug inside the Netty integration when dealing with empty responses.
>>
>> The issue is fixed in 3.0.10, which is included in Wildly 8.2.0
>>
>> We tried to rebase onto Widlfly 8.2.0 but we had some issues with CDI [1].
>>
>> What should we do?
>>
>> If upgrade not possible, do we add Resteasy 3.0.10 as module and depend on that instead?
>>
>> Cheers,
>>
>> [1] https://github.com/infinispan/infinispan/pull/3216
>> [2] https://issues.jboss.org/browse/WFLY-4250
>> --
>> 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
>

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

From sebastian.laskawiec at gmail.com  Mon Apr 13 04:58:28 2015
From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=)
Date: Mon, 13 Apr 2015 08:58:28 +0000
Subject: [infinispan-dev] Quickstarts consolidation
In-Reply-To: <25EC0BA2-4ADA-4AD4-B221-EDEC854138FB@redhat.com>
References: <CADP5VTWR9pzSvhqLeGfKPb0536_e-UcOpCx+a+trLXs=op+4hw@mail.gmail.com>
	<25EC0BA2-4ADA-4AD4-B221-EDEC854138FB@redhat.com>
Message-ID: <CADP5VTWATLzzCXxJ7JOGCOchYNJ0J=L+mODaOhgcCvnQpqfb0w@mail.gmail.com>

Hey Galder

I added 2 new subtasks to [1]. I'm planning to migrate them before closing
the repository [3].

Thanks
Sebastian

pt., 10 kwi 2015 o 18:22 u?ytkownik Galder Zamarre?o <galder at redhat.com>
napisa?:

> Hey Sebastian,
>
> I like the idea but hat about jboss-as7 and jcache quickstarts in [3] ?
> Where are those in [2]?
>
> Cheers,
>
> > On 9 Apr 2015, at 15:03, Sebastian ?askawiec <
> sebastian.laskawiec at gmail.com> wrote:
> >
> > Hey!
> >
> > I'm working on consolidating quickstarts [1] and I would like to ask for
> your opinion.
> >
> > Currently we have 2 quickstarts repositories - jboss-jdg-quickstarts [2]
> and infinispan-quickstart [3]. I think the latter repository is redundant
> and can be closed. There are at least 2 arguments for it - Infinispan web
> page points to the jboss-jdg-quickstarts repo [4] and all relevant
> quickstarts have been already migrated.
> >
> > What do you think?
> >
> > Thanks
> > Sebastian
> >
> > [1] https://issues.jboss.org/browse/ISPN-3654
> > [2] https://github.com/jboss-developer/jboss-jdg-quickstarts
> > [3] https://github.com/infinispan/infinispan-quickstart
> > [4] http://infinispan.org/quickstarts/
> > _______________________________________________
> > 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/20150413/76d33b9d/attachment-0001.html 

From ttarrant at redhat.com  Mon Apr 13 07:48:39 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 13 Apr 2015 13:48:39 +0200
Subject: [infinispan-dev] My weekly update
Message-ID: <552BAD17.2060005@redhat.com>

Hi all,

unfortunately I cannot attend today's weekly update. So here it is 
(together with the previous week, because we skipped last week's):

Galder and I had a very productive 4 day face-to-face at my place 
talking about the Infinispan 8 API changes. We also met with Mario Fusco 
of Drools and "Java 8 in Action" fame who gave us some really precious 
suggestions. Galder has collected most of the ideas on the "cache" side 
whereas I will soon write-up the plans for the "container".

As for coding, here's a breakdown by Jira:

ISPN-5355 - fixed: it was a bug lurking under some wrong assumptions in 
the configuration inheritance code.
ISPN-5359 - removed some really old server parsers. We should actually 
remove some more during the 8.x cycle.
ISPN-5147 - replaced all of the server attribute/add/remove handlers so 
that we don't trigger a global "require-reload" from the server, but 
just restarting the affected cache. I want to extend this so that server 
attributes actually "know" whether a configuration attribute is runtime 
modifiable so that we can apply it immediately.
ISPN-5351 - make sure that certain attributes get copied correctly 
between configurations (especially TypedProperties)

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

From ttarrant at redhat.com  Mon Apr 13 11:24:19 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 13 Apr 2015 17:24:19 +0200
Subject: [infinispan-dev] Preparing for 7.2.0.CR1 for Friday
Message-ID: <552BDFA3.1030208@redhat.com>

Hi all,

we should be releasing 7.2.0.CR1 on Friday and we have several pending 
PRs that need to be reviewed and pushed by then. Can I please ask 
everybody to spend some extra time reviewing and pushing these ?

Thanks

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

From vblagoje at redhat.com  Fri Apr 17 12:02:08 2015
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Fri, 17 Apr 2015 12:02:08 -0400
Subject: [infinispan-dev] [Web admin console] Which stats/metrics do you
	want to see?
Message-ID: <55312E80.5060902@redhat.com>

Hellousers/admins,

Which particular statistics/metrics do you want to see for caches and 
nodes in our new admin console we are developing [1]? We have created a 
wiki page [2] to hear your preferences. Your feedback is valuable and 
appreciated.

Regards,
Vladimir


[1] https://github.com/infinispan/infinispan-management-console
[2] 
https://github.com/infinispan/infinispan-management-console/wiki/Cache-and-node-views

From gustavo at infinispan.org  Fri Apr 17 17:25:42 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Fri, 17 Apr 2015 22:25:42 +0100
Subject: [infinispan-dev] Infinispan 7.2.0.CR1 released!
Message-ID: <CAH8Ud1EzQrkMGEfQ=Tqvsr4cxVzoyp0qC_PO4+sv+q3=fxEnAQ@mail.gmail.com>

Dear all,

We are proud to announce the first release candidate for Infinispan 7.2!

Release details on
http://blog.infinispan.org/2015/04/infinispan-720cr1-released.html


Cheers,
Gustavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150417/9c87671a/attachment.html 

From sanne at infinispan.org  Fri Apr 17 18:41:50 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Fri, 17 Apr 2015 23:41:50 +0100
Subject: [infinispan-dev] Infinispan 7.2.0.CR1 released!
In-Reply-To: <CAH8Ud1EzQrkMGEfQ=Tqvsr4cxVzoyp0qC_PO4+sv+q3=fxEnAQ@mail.gmail.com>
References: <CAH8Ud1EzQrkMGEfQ=Tqvsr4cxVzoyp0qC_PO4+sv+q3=fxEnAQ@mail.gmail.com>
Message-ID: <CAFm4XO0QOK9w9gY824kVL68xp7L9Si81frTTpdaP2Et91V_C9w@mail.gmail.com>

Thanks all, I'm very excited to be able to play with multi-get now :)

On 17 April 2015 at 22:25, Gustavo Fernandes <gustavo at infinispan.org> wrote:
> Dear all,
>
> We are proud to announce the first release candidate for Infinispan 7.2!
>
> Release details on
> http://blog.infinispan.org/2015/04/infinispan-720cr1-released.html
>
>
> Cheers,
> Gustavo
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From mudokonman at gmail.com  Fri Apr 17 19:01:22 2015
From: mudokonman at gmail.com (William Burns)
Date: Fri, 17 Apr 2015 23:01:22 +0000
Subject: [infinispan-dev] Infinispan 7.2.0.CR1 released!
In-Reply-To: <CAFm4XO0QOK9w9gY824kVL68xp7L9Si81frTTpdaP2Et91V_C9w@mail.gmail.com>
References: <CAH8Ud1EzQrkMGEfQ=Tqvsr4cxVzoyp0qC_PO4+sv+q3=fxEnAQ@mail.gmail.com>
	<CAFm4XO0QOK9w9gY824kVL68xp7L9Si81frTTpdaP2Et91V_C9w@mail.gmail.com>
Message-ID: <CA+YCuUNzki0WK9h1PYenzNH=3GsgXzvOO4udbwo0NHYk4mE8-w@mail.gmail.com>

Just a quick clarification.  The multi-get is only available for the
embedded API (remote should be coming into master next week).  The
multi-put however is available for both embedded and remote cache.

Hope you enjoy the new changes!

 - Will

On Fri, Apr 17, 2015 at 6:42 PM Sanne Grinovero <sanne at infinispan.org>
wrote:

> Thanks all, I'm very excited to be able to play with multi-get now :)
>
> On 17 April 2015 at 22:25, Gustavo Fernandes <gustavo at infinispan.org>
> wrote:
> > Dear all,
> >
> > We are proud to announce the first release candidate for Infinispan 7.2!
> >
> > Release details on
> > http://blog.infinispan.org/2015/04/infinispan-720cr1-released.html
> >
> >
> > Cheers,
> > Gustavo
> >
> > _______________________________________________
> > 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/20150417/7f827db0/attachment.html 

From sanne at infinispan.org  Tue Apr 21 09:25:54 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 21 Apr 2015 14:25:54 +0100
Subject: [infinispan-dev] Hanging state transfer
Message-ID: <CAFm4XO2FKrJ_8ZKNyaX2wZgcS31d2RZGm6VMf2dNk_TjiQDvGA@mail.gmail.com>

Hi all,
any idea or suggestion please? Thread dumps are attached.

It's running two WildFly 9 instances, in "standalone" mode so I don't
expect other JGroups channels to be open.
I deploy an Hibernate Search application in them, and this simply
starts a CacheManager. That hangs on start().

If I run the exact same test, with exact same Infinispan version
(7.1.1.Final) on WildFly 8.2 + the as modules (embedded) distributed
by the Infinispan release it works just fine.

Wildfly 9 includes this Infinispan version, so the difference is that
now I'm running the modules which are shipped with WildFly 9 directly:
this should work for end users w/o additional downloads.

Don't take the current master of WF9 as reference: there are some
(other) problems with these modules, so I'm fixing them.. the other
problems were classloader / Search / Hibernate related and I have
patches for those, this run is using them.
But this one I don't understand? Any idea of what to look for? It's
probably caused by some extension point too much, or too few, but it's
not giving a hint.

Another notable difference, is that Infinispan 7.1.1.Final shipped
with JGroups 3.6.1.Final - so that's what I'm using in the version
which works - while WildFly 9 is using JGroups 3.6.2.Final.
I've tried to patch WildFly9 to use the older JGroups but it didn't
change the result.

Thanks,
Sanne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server1
Type: application/octet-stream
Size: 147755 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150421/9d70faf0/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server2
Type: application/octet-stream
Size: 169018 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150421/9d70faf0/attachment-0003.obj 

From an1310 at hotmail.com  Tue Apr 21 12:23:04 2015
From: an1310 at hotmail.com (Erik Salter)
Date: Tue, 21 Apr 2015 12:23:04 -0400
Subject: [infinispan-dev] Hanging state transfer
In-Reply-To: <CAFm4XO2FKrJ_8ZKNyaX2wZgcS31d2RZGm6VMf2dNk_TjiQDvGA@mail.gmail.com>
References: <CAFm4XO2FKrJ_8ZKNyaX2wZgcS31d2RZGm6VMf2dNk_TjiQDvGA@mail.gmail.com>
Message-ID: <BLU437-SMTP21DD8A7E9FF8498D4C6399C3EF0@phx.gbl>

Hi Sanne,

This looks a lot like ISPN-5106
<https://issues.jboss.org/browse/ISPN-5106>  If it is, I work around it in
my production environment by not having my nodes wait on the initial state
transfer.

Erik

On 4/21/15, 9:25 AM, "Sanne Grinovero" <sanne at infinispan.org> wrote:

>Hi all,
>any idea or suggestion please? Thread dumps are attached.
>
>It's running two WildFly 9 instances, in "standalone" mode so I don't
>expect other JGroups channels to be open.
>I deploy an Hibernate Search application in them, and this simply
>starts a CacheManager. That hangs on start().
>
>If I run the exact same test, with exact same Infinispan version
>(7.1.1.Final) on WildFly 8.2 + the as modules (embedded) distributed
>by the Infinispan release it works just fine.
>
>Wildfly 9 includes this Infinispan version, so the difference is that
>now I'm running the modules which are shipped with WildFly 9 directly:
>this should work for end users w/o additional downloads.
>
>Don't take the current master of WF9 as reference: there are some
>(other) problems with these modules, so I'm fixing them.. the other
>problems were classloader / Search / Hibernate related and I have
>patches for those, this run is using them.
>But this one I don't understand? Any idea of what to look for? It's
>probably caused by some extension point too much, or too few, but it's
>not giving a hint.
>
>Another notable difference, is that Infinispan 7.1.1.Final shipped
>with JGroups 3.6.1.Final - so that's what I'm using in the version
>which works - while WildFly 9 is using JGroups 3.6.2.Final.
>I've tried to patch WildFly9 to use the older JGroups but it didn't
>change the result.
>
>Thanks,
>Sanne
>_______________________________________________
>infinispan-dev mailing list
>infinispan-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/infinispan-dev



From sanne at infinispan.org  Tue Apr 21 14:20:07 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 21 Apr 2015 19:20:07 +0100
Subject: [infinispan-dev] Hanging state transfer
In-Reply-To: <BLU437-SMTP21DD8A7E9FF8498D4C6399C3EF0@phx.gbl>
References: <CAFm4XO2FKrJ_8ZKNyaX2wZgcS31d2RZGm6VMf2dNk_TjiQDvGA@mail.gmail.com>
	<BLU437-SMTP21DD8A7E9FF8498D4C6399C3EF0@phx.gbl>
Message-ID: <CAFm4XO0x+7P9oNSyDj=nJOC8JCMDw=dMbKWvKjUDi6TLd9Hi6g@mail.gmail.com>

I've resolved it, thanks all - especially Erik and Dan for their suggestions.

The problem was a hidden exception being swallowed somewhere in the
deployment stack: a "not serializable" exception which pointed to a
classloader issue during bootup, as my custom Externalizer wasn't
registered.

After fixing my classloader issue I'll see if I can figure were things
are being silently swallowed. Would be nice if someone in Infinispan
core could make sure that the state-transfer isn't going to spin
forever in such a case? I'd rather have the sending node at least
reply with some kind of abort code.

Thanks,
Sanne

On 21 April 2015 at 17:23, Erik Salter <an1310 at hotmail.com> wrote:
> Hi Sanne,
>
> This looks a lot like ISPN-5106
> <https://issues.jboss.org/browse/ISPN-5106>  If it is, I work around it in
> my production environment by not having my nodes wait on the initial state
> transfer.
>
> Erik
>
> On 4/21/15, 9:25 AM, "Sanne Grinovero" <sanne at infinispan.org> wrote:
>
>>Hi all,
>>any idea or suggestion please? Thread dumps are attached.
>>
>>It's running two WildFly 9 instances, in "standalone" mode so I don't
>>expect other JGroups channels to be open.
>>I deploy an Hibernate Search application in them, and this simply
>>starts a CacheManager. That hangs on start().
>>
>>If I run the exact same test, with exact same Infinispan version
>>(7.1.1.Final) on WildFly 8.2 + the as modules (embedded) distributed
>>by the Infinispan release it works just fine.
>>
>>Wildfly 9 includes this Infinispan version, so the difference is that
>>now I'm running the modules which are shipped with WildFly 9 directly:
>>this should work for end users w/o additional downloads.
>>
>>Don't take the current master of WF9 as reference: there are some
>>(other) problems with these modules, so I'm fixing them.. the other
>>problems were classloader / Search / Hibernate related and I have
>>patches for those, this run is using them.
>>But this one I don't understand? Any idea of what to look for? It's
>>probably caused by some extension point too much, or too few, but it's
>>not giving a hint.
>>
>>Another notable difference, is that Infinispan 7.1.1.Final shipped
>>with JGroups 3.6.1.Final - so that's what I'm using in the version
>>which works - while WildFly 9 is using JGroups 3.6.2.Final.
>>I've tried to patch WildFly9 to use the older JGroups but it didn't
>>change the result.
>>
>>Thanks,
>>Sanne
>>_______________________________________________
>>infinispan-dev mailing list
>>infinispan-dev at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From sanne at infinispan.org  Tue Apr 21 18:46:38 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 21 Apr 2015 23:46:38 +0100
Subject: [infinispan-dev] Merging of integration testing modules
Message-ID: <CAFm4XO0wuhNPfHK4ZSGtZZMvCFc3HkEhfzfNzOnqzLs9wQS_Cg@mail.gmail.com>

Hi all,
as I was exploring the source tree for potentially interesting tests
to run on WildFly 9, I'm getting a bit confused by the amount of
testing modules.

For example, I have no idea why there is a module
"infinispan-embedded-query-it" which apparently contains some more
tests for "infinispan-query" - but above all I'm not seeing why such
tests should be living in a separate module.
Also, it looks like there might possibly be quite some redundancy on
top of existing tests.

In a similar way, I'm aware "infinispan-as-lucene-integration" was
just created as we migrated those from Hibernate Search. But we could
merge that in our existing integration tests right?

Ideally I was hoping that an activity like a WildFly upgrade would
touch just a couple of modules; I think the only reason we should have
to separate these in different modules is if it's really important to
not have some module installed.
If we could achieve that, it should be easier to then start the
container only once (twice) to run all tests quicker?

Thanks,
Sanne

From gustavo at infinispan.org  Wed Apr 22 02:51:32 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Wed, 22 Apr 2015 07:51:32 +0100
Subject: [infinispan-dev] Merging of integration testing modules
In-Reply-To: <CAFm4XO0wuhNPfHK4ZSGtZZMvCFc3HkEhfzfNzOnqzLs9wQS_Cg@mail.gmail.com>
References: <CAFm4XO0wuhNPfHK4ZSGtZZMvCFc3HkEhfzfNzOnqzLs9wQS_Cg@mail.gmail.com>
Message-ID: <CAH8Ud1GEsgj6CrXTtvGMGARHL69D+YXmzHcJPBvKDhwHCP3nPA@mail.gmail.com>

On Tue, Apr 21, 2015 at 11:46 PM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> Hi all,
> as I was exploring the source tree for potentially interesting tests
> to run on WildFly 9, I'm getting a bit confused by the amount of
> testing modules.
>
> For example, I have no idea why there is a module
> "infinispan-embedded-query-it" which apparently contains some more
> tests for "infinispan-query" - but above all I'm not seeing why such
> tests should be living in a separate module.
>

Those are tests for the query uberjar, they do not involve any container.



> Also, it looks like there might possibly be quite some redundancy on
> top of existing tests.
>
> In a similar way, I'm aware "infinispan-as-lucene-integration" was
> just created as we migrated those from Hibernate Search. But we could
> merge that in our existing integration tests right?
>


This was created last year to test the Lucene Directory. Now it is also
testing
the Infinispan Directory Provider since we migrated it from Search.


>
> Ideally I was hoping that an activity like a WildFly upgrade would
> touch just a couple of modules; I think the only reason we should have
> to separate these in different modules is if it's really important to
> not have some module installed.
> If we could achieve that, it should be easier to then start the
> container only once (twice) to run all tests quicker?
>

Assuming they install the same modules and wildfly configuration used is
compatible, +1


>
> Thanks,
> Sanne
> _______________________________________________
> 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/20150422/811c422e/attachment.html 

From jholusa at redhat.com  Wed Apr 22 08:57:34 2015
From: jholusa at redhat.com (Jiri Holusa)
Date: Wed, 22 Apr 2015 08:57:34 -0400 (EDT)
Subject: [infinispan-dev] Merging of integration testing modules
In-Reply-To: <CAFm4XO0wuhNPfHK4ZSGtZZMvCFc3HkEhfzfNzOnqzLs9wQS_Cg@mail.gmail.com>
References: <CAFm4XO0wuhNPfHK4ZSGtZZMvCFc3HkEhfzfNzOnqzLs9wQS_Cg@mail.gmail.com>
Message-ID: <1163048457.3256397.1429707454509.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Sanne Grinovero" <sanne at infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Sent: Wednesday, April 22, 2015 12:46:38 AM
> Subject: [infinispan-dev] Merging of integration testing modules
> 
> Hi all,
> as I was exploring the source tree for potentially interesting tests
> to run on WildFly 9, I'm getting a bit confused by the amount of
> testing modules.
> 
> For example, I have no idea why there is a module
> "infinispan-embedded-query-it" which apparently contains some more
> tests for "infinispan-query" - but above all I'm not seeing why such
> tests should be living in a separate module.
> Also, it looks like there might possibly be quite some redundancy on
> top of existing tests.

This module was created for testing of uberjars. According to chat with Tristan, we had to make sure that no dependencies will be pulled other than uberjars. But don't worry, we are planning to change this somehow that we would run the whole testsuite just with uberjars, so there would be no test duplication, but first we need to figure out how.

> 
> In a similar way, I'm aware "infinispan-as-lucene-integration" was
> just created as we migrated those from Hibernate Search. But we could
> merge that in our existing integration tests right?
> 
> Ideally I was hoping that an activity like a WildFly upgrade would
> touch just a couple of modules; I think the only reason we should have
> to separate these in different modules is if it's really important to
> not have some module installed.
> If we could achieve that, it should be easier to then start the
> container only once (twice) to run all tests quicker?
> 
> Thanks,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

From sanne at infinispan.org  Wed Apr 22 09:03:20 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 22 Apr 2015 14:03:20 +0100
Subject: [infinispan-dev] Merging of integration testing modules
In-Reply-To: <1163048457.3256397.1429707454509.JavaMail.zimbra@redhat.com>
References: <CAFm4XO0wuhNPfHK4ZSGtZZMvCFc3HkEhfzfNzOnqzLs9wQS_Cg@mail.gmail.com>
	<1163048457.3256397.1429707454509.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO1M0zKRkJ5nLbEnQxpbZpPLQqvv09Pv_M4ByxsiYEdH=A@mail.gmail.com>

Ok, thanks for all explanations!
Sorry I felt a bit lost but it makes sense, let's just hope to keep
working on minimizing these in the future.

Sanne

On 22 April 2015 at 13:57, Jiri Holusa <jholusa at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Sanne Grinovero" <sanne at infinispan.org>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Sent: Wednesday, April 22, 2015 12:46:38 AM
>> Subject: [infinispan-dev] Merging of integration testing modules
>>
>> Hi all,
>> as I was exploring the source tree for potentially interesting tests
>> to run on WildFly 9, I'm getting a bit confused by the amount of
>> testing modules.
>>
>> For example, I have no idea why there is a module
>> "infinispan-embedded-query-it" which apparently contains some more
>> tests for "infinispan-query" - but above all I'm not seeing why such
>> tests should be living in a separate module.
>> Also, it looks like there might possibly be quite some redundancy on
>> top of existing tests.
>
> This module was created for testing of uberjars. According to chat with Tristan, we had to make sure that no dependencies will be pulled other than uberjars. But don't worry, we are planning to change this somehow that we would run the whole testsuite just with uberjars, so there would be no test duplication, but first we need to figure out how.
>
>>
>> In a similar way, I'm aware "infinispan-as-lucene-integration" was
>> just created as we migrated those from Hibernate Search. But we could
>> merge that in our existing integration tests right?
>>
>> Ideally I was hoping that an activity like a WildFly upgrade would
>> touch just a couple of modules; I think the only reason we should have
>> to separate these in different modules is if it's really important to
>> not have some module installed.
>> If we could achieve that, it should be easier to then start the
>> container only once (twice) to run all tests quicker?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From ttarrant at redhat.com  Wed Apr 22 09:18:39 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 22 Apr 2015 15:18:39 +0200
Subject: [infinispan-dev] Merging of integration testing modules
In-Reply-To: <CAFm4XO1M0zKRkJ5nLbEnQxpbZpPLQqvv09Pv_M4ByxsiYEdH=A@mail.gmail.com>
References: <CAFm4XO0wuhNPfHK4ZSGtZZMvCFc3HkEhfzfNzOnqzLs9wQS_Cg@mail.gmail.com>	<1163048457.3256397.1429707454509.JavaMail.zimbra@redhat.com>
	<CAFm4XO1M0zKRkJ5nLbEnQxpbZpPLQqvv09Pv_M4ByxsiYEdH=A@mail.gmail.com>
Message-ID: <55379FAF.8080807@redhat.com>

Also the securitymanager tests need to be separate since they need to 
run ... with a securitymanager, which is per-JVM and screws everything 
up otherwise.

Tristan

On 22/04/2015 15:03, Sanne Grinovero wrote:
> Ok, thanks for all explanations!
> Sorry I felt a bit lost but it makes sense, let's just hope to keep
> working on minimizing these in the future.
>
> Sanne
>
> On 22 April 2015 at 13:57, Jiri Holusa <jholusa at redhat.com> wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Sanne Grinovero" <sanne at infinispan.org>
>>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>>> Sent: Wednesday, April 22, 2015 12:46:38 AM
>>> Subject: [infinispan-dev] Merging of integration testing modules
>>>
>>> Hi all,
>>> as I was exploring the source tree for potentially interesting tests
>>> to run on WildFly 9, I'm getting a bit confused by the amount of
>>> testing modules.
>>>
>>> For example, I have no idea why there is a module
>>> "infinispan-embedded-query-it" which apparently contains some more
>>> tests for "infinispan-query" - but above all I'm not seeing why such
>>> tests should be living in a separate module.
>>> Also, it looks like there might possibly be quite some redundancy on
>>> top of existing tests.
>>
>> This module was created for testing of uberjars. According to chat with Tristan, we had to make sure that no dependencies will be pulled other than uberjars. But don't worry, we are planning to change this somehow that we would run the whole testsuite just with uberjars, so there would be no test duplication, but first we need to figure out how.
>>
>>>
>>> In a similar way, I'm aware "infinispan-as-lucene-integration" was
>>> just created as we migrated those from Hibernate Search. But we could
>>> merge that in our existing integration tests right?
>>>
>>> Ideally I was hoping that an activity like a WildFly upgrade would
>>> touch just a couple of modules; I think the only reason we should have
>>> to separate these in different modules is if it's really important to
>>> not have some module installed.
>>> If we could achieve that, it should be easier to then start the
>>> container only once (twice) to run all tests quicker?
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>

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

From rory.odonnell at oracle.com  Fri Apr 24 03:55:26 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 24 Apr 2015 08:55:26 +0100
Subject: [infinispan-dev] Early Access builds for JDK 9 b60 and JDK 8u60 b12
 are available on java.net
Message-ID: <5539F6EE.3050903@oracle.com>

Hi Galder,

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

Early Access build for JDK 8u60 b12 <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-b12.html>

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/20150424/e21d0e55/attachment.html 

From gustavo at infinispan.org  Tue Apr 28 10:46:21 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Tue, 28 Apr 2015 15:46:21 +0100
Subject: [infinispan-dev] Remote Iterator design doc
Message-ID: <CAH8Ud1E_-B3PuiAP7LZ2cMicasFFeNjFndaM64xGbm-VcgnP6A@mail.gmail.com>

Hi all, just updated [1]

Comments and feedback appreciated!

[1] https://github.com/infinispan/infinispan/wiki/Remote-Iterator

Thanks,
Gustavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150428/0c809cf4/attachment.html 

From rvansa at redhat.com  Tue Apr 28 11:22:30 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Tue, 28 Apr 2015 17:22:30 +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: <553FA5B6.6020809@redhat.com>

Why are segments specified as byte[]? Shouldn't that be rather vInt[]?

R.

On 04/28/2015 04:46 PM, Gustavo Fernandes 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


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


From gustavo at infinispan.org  Tue Apr 28 12:44:59 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Tue, 28 Apr 2015 17:44:59 +0100
Subject: [infinispan-dev] Remote Iterator design doc
In-Reply-To: <553FA5B6.6020809@redhat.com>
References: <CAH8Ud1E_-B3PuiAP7LZ2cMicasFFeNjFndaM64xGbm-VcgnP6A@mail.gmail.com>
	<553FA5B6.6020809@redhat.com>
Message-ID: <CAH8Ud1H6f=xuPOBYRNaoNrg9OeMgeBB3mkWRkmZD+g7T-KxnpQ@mail.gmail.com>

On Tue, Apr 28, 2015 at 4:22 PM, Radim Vansa <rvansa at redhat.com> wrote:

> Why are segments specified as byte[]? Shouldn't that be rather vInt[]?
>
>
The motivation is to use some sort of bitset encoding for the segment ids
rather than send each one as vInt.


Gustavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150428/06d60940/attachment.html 

From sanne at infinispan.org  Tue Apr 28 12:56:44 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 28 Apr 2015 17:56:44 +0100
Subject: [infinispan-dev] Slow CI slaves?
Message-ID: <CAFm4XO0Mezk3MAiLHfDkzWNVUEe4wBJyp7OpxMKWbvTPWxeKQg@mail.gmail.com>

Hi all,
are the CI slaves in good condition?

I've sent a PR 17 hours ago and it has still not produced a report.
Since I'm having a puzzling failure locally, it would be useful to
compare with the CI results and its failure history.

Should we add some more slaves? There are free servers available in OS1.

Sanne

From sebastian.laskawiec at gmail.com  Tue Apr 28 13:28:45 2015
From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=)
Date: Tue, 28 Apr 2015 17:28:45 +0000
Subject: [infinispan-dev] Slow CI slaves?
In-Reply-To: <CAFm4XO0Mezk3MAiLHfDkzWNVUEe4wBJyp7OpxMKWbvTPWxeKQg@mail.gmail.com>
References: <CAFm4XO0Mezk3MAiLHfDkzWNVUEe4wBJyp7OpxMKWbvTPWxeKQg@mail.gmail.com>
Message-ID: <CADP5VTVt74YkJ1wcjKQczO44bE0D+OPkDdAwp3EZWiVvA6Bw6w@mail.gmail.com>

Hey Sanne!

I believe your PR is building right now [1]. Currently the queue's size is 7,
which means that the last PR will be built in 5-6 hours [2].

Yes, I totally agree, it would be great to have more nodes (2 maybe 3
more?).

Thanks
Sebastian

[1]
http://ci.infinispan.org/viewLog.html?buildId=25791&tab=buildResultsDiv&buildTypeId=bt9
[2] http://ci.infinispan.org/queue.html



wt., 28.04.2015 o 18:57 u?ytkownik Sanne Grinovero <sanne at infinispan.org>
napisa?:

> Hi all,
> are the CI slaves in good condition?
>
> I've sent a PR 17 hours ago and it has still not produced a report.
> Since I'm having a puzzling failure locally, it would be useful to
> compare with the CI results and its failure history.
>
> Should we add some more slaves? There are free servers available in OS1.
>
> Sanne
> _______________________________________________
> 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/20150428/78c09e41/attachment.html 

From sanne at infinispan.org  Tue Apr 28 13:37:36 2015
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 28 Apr 2015 18:37:36 +0100
Subject: [infinispan-dev] Slow CI slaves?
In-Reply-To: <CADP5VTVt74YkJ1wcjKQczO44bE0D+OPkDdAwp3EZWiVvA6Bw6w@mail.gmail.com>
References: <CAFm4XO0Mezk3MAiLHfDkzWNVUEe4wBJyp7OpxMKWbvTPWxeKQg@mail.gmail.com>
	<CADP5VTVt74YkJ1wcjKQczO44bE0D+OPkDdAwp3EZWiVvA6Bw6w@mail.gmail.com>
Message-ID: <CAFm4XO2UTF0HjHs7zkYmS18zjVTEqQtFL0C68igLMc5FbjLU0A@mail.gmail.com>

yes, let's start 3 more?
I'm assuming you have setup of a new node mostly scripted?

On 28 April 2015 at 18:28, Sebastian ?askawiec
<sebastian.laskawiec at gmail.com> wrote:
> Hey Sanne!
>
> I believe your PR is building right now [1]. Currently the queue's size is
> 7, which means that the last PR will be built in 5-6 hours [2].
>
> Yes, I totally agree, it would be great to have more nodes (2 maybe 3
> more?).
>
> Thanks
> Sebastian
>
> [1]
> http://ci.infinispan.org/viewLog.html?buildId=25791&tab=buildResultsDiv&buildTypeId=bt9
> [2] http://ci.infinispan.org/queue.html
>
>
>
> wt., 28.04.2015 o 18:57 u?ytkownik Sanne Grinovero <sanne at infinispan.org>
> napisa?:
>>
>> Hi all,
>> are the CI slaves in good condition?
>>
>> I've sent a PR 17 hours ago and it has still not produced a report.
>> Since I'm having a puzzling failure locally, it would be useful to
>> compare with the CI results and its failure history.
>>
>> Should we add some more slaves? There are free servers available in OS1.
>>
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From isavin at redhat.com  Tue Apr 28 14:22:15 2015
From: isavin at redhat.com (Ion Savin)
Date: Tue, 28 Apr 2015 21:22:15 +0300
Subject: [infinispan-dev] Slow CI slaves?
In-Reply-To: <CAFm4XO2UTF0HjHs7zkYmS18zjVTEqQtFL0C68igLMc5FbjLU0A@mail.gmail.com>
References: <CAFm4XO0Mezk3MAiLHfDkzWNVUEe4wBJyp7OpxMKWbvTPWxeKQg@mail.gmail.com>	<CADP5VTVt74YkJ1wcjKQczO44bE0D+OPkDdAwp3EZWiVvA6Bw6w@mail.gmail.com>
	<CAFm4XO2UTF0HjHs7zkYmS18zjVTEqQtFL0C68igLMc5FbjLU0A@mail.gmail.com>
Message-ID: <553FCFD7.3050809@redhat.com>

It is not scripted but you can simply do a snapshot of one of the 
existing VMs + a few config changes.

--
Ion Savin

On 04/28/2015 08:37 PM, Sanne Grinovero wrote:
> yes, let's start 3 more?
> I'm assuming you have setup of a new node mostly scripted?
>
> On 28 April 2015 at 18:28, Sebastian ?askawiec
> <sebastian.laskawiec at gmail.com> wrote:
>> Hey Sanne!
>>
>> I believe your PR is building right now [1]. Currently the queue's size is
>> 7, which means that the last PR will be built in 5-6 hours [2].
>>
>> Yes, I totally agree, it would be great to have more nodes (2 maybe 3
>> more?).
>>
>> Thanks
>> Sebastian
>>
>> [1]
>> http://ci.infinispan.org/viewLog.html?buildId=25791&tab=buildResultsDiv&buildTypeId=bt9
>> [2] http://ci.infinispan.org/queue.html
>>
>>
>>
>> wt., 28.04.2015 o 18:57 u?ytkownik Sanne Grinovero <sanne at infinispan.org>
>> napisa?:
>>>
>>> Hi all,
>>> are the CI slaves in good condition?
>>>
>>> I've sent a PR 17 hours ago and it has still not produced a report.
>>> Since I'm having a puzzling failure locally, it would be useful to
>>> compare with the CI results and its failure history.
>>>
>>> Should we add some more slaves? There are free servers available in OS1.
>>>
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


From vjuranek at redhat.com  Tue Apr 28 15:35:31 2015
From: vjuranek at redhat.com (Vojtech Juranek)
Date: Tue, 28 Apr 2015 21:35:31 +0200
Subject: [infinispan-dev] Slow CI slaves?
In-Reply-To: <CAFm4XO0Mezk3MAiLHfDkzWNVUEe4wBJyp7OpxMKWbvTPWxeKQg@mail.gmail.com>
References: <CAFm4XO0Mezk3MAiLHfDkzWNVUEe4wBJyp7OpxMKWbvTPWxeKQg@mail.gmail.com>
Message-ID: <1650568.I65Yb8X4kY@localhost>

Hi,

> Should we add some more slaves?

wouldn't it be better to provision slaves dynamically according to the current 
queue length instead of just adding more machines? After all, that's the main 
point of the cloud ... 

Vojta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20150428/a88d57bb/attachment-0001.bin 

From isavin at redhat.com  Wed Apr 29 02:48:01 2015
From: isavin at redhat.com (Ion Savin)
Date: Wed, 29 Apr 2015 09:48:01 +0300
Subject: [infinispan-dev] Slow CI slaves?
In-Reply-To: <1650568.I65Yb8X4kY@localhost>
References: <CAFm4XO0Mezk3MAiLHfDkzWNVUEe4wBJyp7OpxMKWbvTPWxeKQg@mail.gmail.com>
	<1650568.I65Yb8X4kY@localhost>
Message-ID: <55407EA1.6040508@redhat.com>

Hi,

As far as I know there is a limit on the number of machines we can use 
and unless that limit changed recently we are already using the maximum 
number of VMs we are allowed to use.

--
Ion Savin

On 04/28/2015 10:35 PM, Vojtech Juranek wrote:
> Hi,
>
>> Should we add some more slaves?
>
> wouldn't it be better to provision slaves dynamically according to the current
> queue length instead of just adding more machines? After all, that's the main
> point of the cloud ...
>
> Vojta
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


From slaskawi at redhat.com  Wed Apr 29 10:02:28 2015
From: slaskawi at redhat.com (=?UTF-8?B?U2ViYXN0aWFuIMWBYXNrYXdpZWM=?=)
Date: Wed, 29 Apr 2015 16:02:28 +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: <5540E474.8010107@redhat.com>

Hey Gustavo!

Just a small question - could you tell me please why are we using name 
CloseableIterator? A RemoteIterator seems more "natural" in this case.

Thanks
Sebastian

On 04/28/2015 04:46 PM, Gustavo Fernandes 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

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

From gustavo at infinispan.org  Wed Apr 29 16:50:21 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Wed, 29 Apr 2015 21:50:21 +0100
Subject: [infinispan-dev] Remote Iterator design doc
In-Reply-To: <5540E474.8010107@redhat.com>
References: <CAH8Ud1E_-B3PuiAP7LZ2cMicasFFeNjFndaM64xGbm-VcgnP6A@mail.gmail.com>
	<5540E474.8010107@redhat.com>
Message-ID: <0C0214B2-58F8-4E7F-99AE-6CDFF3F28CAB@infinispan.org>


> On 29 Apr 2015, at 15:02, Sebastian ?askawiec <slaskawi at redhat.com> wrote:
> 
> Hey Gustavo!
> 
> Just a small question - could you tell me please why are we using name CloseableIterator? A RemoteIterator seems more "natural" in this case.


CloseableIterator is already in the classpath of the hotrod-client (part of commons), so It's just being reused. 

Gustavo

> 
> Thanks
> Sebastian
> 
> On 04/28/2015 04:46 PM, Gustavo Fernandes wrote:
>> Hi all, just updated [1] 
>> 
>> Comments and feedback appreciated!
>> 
>> [1] https://github.com/infinispan/infinispan/wiki/Remote-Iterator <https://github.com/infinispan/infinispan/wiki/Remote-Iterator>
>> 
>> Thanks,
>> Gustavo
>> 
>> 
>> 
>> _______________________________________________
>> 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

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