Hey Dan/Adrian,
Re: https://issues.jboss.org/browse/ISPN-2541
I'm looking at this intermittent failure, and it seems to be caused by the fact
that the test does not wait for the cluster to be formed when the new node is
started, which can lead a replication timeout failure from the new joining
On 4 December 2012 09:14, Galder Zamarreño wrote:
> Hey Dan/Adrian,
>
> Re: https://issues.jboss.org/browse/ISPN-2541
>
> I'm looking at this intermittent failure, and it seems to be caused by the
> fact that the test does not wait for the cluster to be formed when the new
> node is started, whi
On 4 Dec 2012, at 09:22, Sanne Grinovero wrote:
> [...]
>
> I don't think the cache should ever be in an illegal state to be used
> after being started. So Infinispan should not require tests to wait
> for a "cluster to be formed", I'd rather guarantee that after a cache
> is started it's usable
Too big change IMO for 5.2.
@Vladimir, did you check with Mircea which JIRAs you could help with which have
higher prio for 5.2?
Cheers,
On Nov 27, 2012, at 9:07 PM, Vladimir Blagojevic wrote:
> Hi,
>
> Although https://issues.jboss.org/browse/ISPN-2284 is charted for 6.0 I
> would like t
On 4 Dec 2012, at 09:43, Galder Zamarreño wrote:
> Too big change IMO for 5.2.
+1
>
> @Vladimir, did you check with Mircea which JIRAs you could help with which
> have higher prio for 5.2?
Mind looking at some bugs/usability features first: ISPN-2353 and ISPN-2409.
You have a very good pace :-)
On Tue, Dec 4, 2012 at 11:32 AM, Mircea Markus wrote:
>
> On 4 Dec 2012, at 09:22, Sanne Grinovero wrote:
>
> [...]
>
> I don't think the cache should ever be in an illegal state to be used
> after being started. So Infinispan should not require tests to wait
> for a "cluster to be formed", I'd r
On 12/4/12 11:30 AM, Dan Berindei wrote:
> BTW, I also got an exception yesterday in MarshallExternalPojosTest and
> I investigated it, but in my case the error was much weirder: two nodes
> both opened a TCP connection to each other, yet none of them received
> the forwarded command. I've asked
If ti's only for that logic I'd rather have it implemented in Infinispan for
now, as it doesn't seem that complex.
Project dependencies has started to become more and more of an issue (e.g. in
6.0. we want to allow the users to only download a single jar if they need
local cache only) so I'd rat
On Dec 4, 2012, at 12:17 PM, Mircea Markus wrote:
> If ti's only for that logic I'd rather have it implemented in Infinispan for
> now, as it doesn't seem that complex.
^ +1000
In particular, commons libraries can be pretty evil.
> Project dependencies has started
+1000
On 12/4/12 12:17 PM, Mircea Markus wrote:
> If ti's only for that logic I'd rather have it implemented in Infinispan
> for now, as it doesn't seem that complex.
> Project dependencies has started to become more and more of an issue
> (e.g. in 6.0. we want to allow the users to only d
FYI,
a little Christmas present for Dan, who's been bugging me with UNICAST2
quirks that he ran into in Infinispan...
[1] https://issues.jboss.org/browse/JGRP-1548
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
inf
I agree guys, I am also allergic to new dependencies but I was surprised
that we do not have robust mechanism to find root Throwable given an
Exception (and no it is not simply traversing #getCause() as I myself
naively thought). Not even jboss commons has this useful utility.
Cheers,
Vladimir
+1 Galder and Mircea. I wanted confirmation and I got it. I will focus
on these issues you suggest Mircea!
On 12-12-04 4:58 AM, Mircea Markus wrote:
On 4 Dec 2012, at 09:43, Galder Zamarreño wrote:
Too big change IMO for 5.2.
+1
@Vladimir, did you check with Mircea which JIRAs you could he
13 matches
Mail list logo
