gt;
>>
>> --
>>
>> Vittorio Rigamonti
>>
>> Senior Software Engineer
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>>
>> Milan, Italy
>>
>> vriga...@redhat.com
v@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Bela Ban | http://www.jgroups.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
PCs cannot invoke default methods inherited from interfaces
[https://issues.jboss.org/browse/JGRP-2247]
- Fix for FILE_PING (and subclasses, such as
NATIVE_S3_PING/GOOGLE_PING2, JDBC_PING etc) to remove members from the
backend store
[https://issues.jboss.org/browse/JGRP-2232]
Cheers,
--
Bela
the discount.
If you're Red Hat employee, contact me offline for a bigger discount... :-)
Cheers,
[1] http://www.jgroups.org
[2] http://www.jgroups.org/workshops.html
--
Bela Ban | http://www.jgroups.org
___
infinispan-dev mailing list
infinispan-dev
hanks,
> Sebastian
>
> On Thu, Aug 10, 2017 at 1:48 PM, Bela Ban <bela...@mailbox.org
> <mailto:bela...@mailbox.org>> wrote:
>
>
> FYI
>
> Forwarded Message
> Subject: [jgroups-users] Revamping the JGroups workshop
>
t's in use as server port:
>>
>> https://github.com/galderz/java-sandbox/blob/master/src/main/java/j/net/LocalPortClash.java
>>
>> I'll check JGRP source and JIRA and try to dig this further.
>>
>> Cheers,
>>
>>> On 14 Aug 2017, at 08:48, Bela Ban <bela...
t
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Bela Ban | http://www.jgroups.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
and
Boston for the US...
Cheers,
[1] http://www.jgroups.org/workshops.html
--
Bela Ban | http://www.jgroups.org
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! htt
...@redhat.com
> <mailto:slask...@redhat.com>>:
>
> Yep, no problems found!!!
>
> I had also impression that the new implementation is "faster".
> Though I haven't measured it... it just my impression.
>
> Awesome work Bela!
>
> On T
FYI: http://belaban.blogspot.ch/2017/06/non-blocking-jgroups.html
--
Bela Ban | http://www.jgroups.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
WIEC
>
> INFINISPAN DEVELOPER
>
> Red Hat EMEA <https://www.redhat.com/>
>
> <https://red.ht/sig>
>
>
>
> _______
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/
gt; > INFINISPAN DEVELOPER
> > Red Hat EMEA
> >
> >
> > ___
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org
> <mailto:infinispan-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listin
Hi folks,
I've deprecated S3_PING [1] and GOOGLE_PING [3]. The replacements are
NATIVE_S3_PING [2] and GOOGLE_PING2 [4].
S3_PING started out as a copy of sample code by Amazon a long time ago,
and - because I never wanted Amazon's dependencies - is quite fat, as it
contains a bunch of
FYI: http://belaban.blogspot.ch/2017/05/running-infinispan-cluster-with.html
--
Bela Ban | http://www.jgroups.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
t;https://www.redhat.com/>
>
> <https://red.ht/sig>
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Bela Ban | http://www.jgroups.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
,
> Vladimir
>
> On 2017-02-21 8:37 AM, Sanne Grinovero wrote:
>> Congratulations!
>>
>> On 21 Feb 2017 12:21, "Bela Ban" <b...@redhat.com
>> <mailto:b...@redhat.com>> wrote:
>>
>> FYI: http://belaban.blogspot.ch/2017/02/jgroups
FYI: http://belaban.blogspot.ch/2017/02/jgroups-400final.html
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
- Remove the tree module: it doesn't work properly, and uses batching
>
> Please cast your votes
>
> Tristan
>
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jbos
ul to users who
> don't know GH that well.
Yes, I said that in my response to them, too
> R.
>
> On 01/12/2017 10:17 AM, Bela Ban wrote:
>> FYI
>>
>> Forwarded Message
>> Subject: Re: Tags don't show up in Tags dropdown menu
>> Date:
FYI
Forwarded Message
Subject:Re: Tags don't show up in Tags dropdown menu
Date: Wed, 11 Jan 2017 16:54:07 -0800
From: Francis (GitHub Staff) <supp...@github.com>
To: Bela Ban <bela...@mailbox.org>
Hi Bela -
Thanks for getting in touch! The
gt;> IMO the clients should poll, but if the server has nothing to return it
>>> blocks until there is something or until a timeout occurs. This makes it
>>> easy for clients and actually reduces network traffic compared to
>>> constantly polling.
>>>
>>> BTW, a lot of
That should not prevent you from running your own tests. Maybe that
software was created with a different use case in mind...
On 27/09/16 11:35, Sebastian Laskawiec wrote:
> Ouch :( The article looked promising :D
>
> Thanks a lot for checking!
>
> On Mon, Sep 26, 2016 at 1:34
You mean pom.xml? :-)
On 06/09/16 19:34, Sanne Grinovero wrote:
> Ah, from the premises I thought that you'd make the JGroups jar lose
> weight by removing some junk files from it.. :P Like the Maven settings
> configuration file ?
>
>
> On 6 Sep 2016 17:09, "Bel
On 06/09/16 18:06, Tristan Tarrant wrote:
> On 06/09/16 17:36, Alan Field wrote:
>>
>> - Original Message -----
>>> From: "Bela Ban" <b...@redhat.com>
>>> To: infinispan-dev@lists.jboss.org
>>> Sent: Tuesday, September 6, 2016 11:14
,
[1] https://issues.jboss.org/browse/JGRP-2047
[2] https://issues.jboss.org/browse/JGRP-2099
[3] https://issues.jboss.org/browse/JGRP-2100
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
Most API changes have been done, 12 issues left. I expect the final
release in October.
Note that JGroups-4.0.0-SNAPSHOT is also generated (on every change, IIRC).
Feedback appreciated!
[1] http://belaban.blogspot.ch/2016/08/jgroups-400alpha1-released.html
--
Bela Ban, JGroups lead (http
On 22/08/16 20:22, Manohar SL wrote:
> Yes, we need some quick help from Infinispan Folks on the needed changes to
> infinispan-config.xml and jgroups.xml to
> get the combination of "Infinispan 8.2.2 with JGroups 3.6.7" working for
> Replication mode of Infinispa
l="5000"
> log_not_found_msgs="true"
>max_bytes="40"/>
> max_bytes="40"/>
> merge_timeout="5000" log_collect_msgs="true" log_view_warnings="true"
&g
On 22/08/16 10:23, Manohar SL wrote:
> Hi Bela Ban,
>
> Thanks for the input points.
>
> Answers are highlighted below:
>
> 1: What does the NPE cause? Incorrect behavior? This is in the discovery
> protocol, so I don't think it is a severe error.
> Actually, w
upgrade JGroups?
4: Is this reproduceable? If yes, goto step #2
On 20/08/16 09:38, Manohar SL wrote:
> Hi Bela Ban,
>
> We have been trying to use JGroups 3.6.8 with Infinispan 8.2.2., in this
> context we are observing an issue with the Replication Mode of Infinispan
>
olution.
>
> Hope that helps,
> Rob
>
>
>
> Hey Bela!
>
> No no, the resolution can be done with pure JDK.
>
> Thanks
> Sebastian
>
> On Fri, Aug 19, 201
On 19/08/16 11:27, Gustavo Fernandes wrote:
> On Fri, Aug 19, 2016 at 10:18 AM, Bela Ban <b...@redhat.com
> <mailto:b...@redhat.com>> wrote:
>
> Hi Sebastian
>
> the usual restrictions apply: if DNS discovery depends on external libs,
> then it s
ups-extras/jgroups-kubernetes/tree/master/dns
> [9] http://stackoverflow.com/a/12405896/562699
> [10] You might need to adjust ImageStream.
> https://gist.github.com/slaskawi/7cffb5588dabb770f654557579c5f2d0
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
me know (via the mailing list) if you encounter any problems.
Cheers,
[1] https://issues.jboss.org/browse/JGRP-2067
--
Bela Ban, JGroups lead (http://www.jgroups.org)
--
What NetFlow Analyzer can do for you? Monitors netwo
pan-dev mailing list
> infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailm
opic on wiki [1] and I would welcome your thoughts about that.
>
> Eventually I'd like to do a performance POC (operations without ST
> implementation).
>
> Radim
>
> [1] https://github.com/infinispan/infinispan/wiki/Scattered-Cache-design-doc
>
--
Bela Ba
On 22/03/16 18:04, Dan Berindei wrote:
> On Mon, Mar 21, 2016 at 1:43 PM, Bela Ban <b...@redhat.com> wrote:
>>
>>
>> On 21/03/16 11:12, Pedro Ruivo wrote:
>>> Hi all,
>>>
>>> @Eric, thanks for the requirements.
>>>
>>> @
gt; -Eric
>
> On 3/18/2016 2:32 AM, Bela Ban wrote:
>> Stupid question: whay do you need a distributed counter for this? Is the
>> service you're monitoring replicated in a cluster?
>>
>> On 17/03/16 18:06, Eric Wittmann wrote:
>>> Greetings. Apologies f
quota values to be lost on server restart.
>
> That's all the high level requirements I can think of off the top of my
> head, and after reading all of the current messages in this thread. :)
>
> -Eric
> _______
> in
comment bellow and let me know alternatives, improvement or if I
>> missed something.
>>
>> ps. I also consider implement a counter based on JGroups-raft but I
>> believe it is an overkill.
>> ps2. sorry for the long email :( I tried to be shorter as possible.
also consider implement a counter based on JGroups-raft but I
> believe it is an overkill.
> ps2. sorry for the long email :( I tried to be shorter as possible.
>
> Cheers,
> Pedro
> ___
> infinispan-dev mailing list
> infinispan
infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
__
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
op
> notification (as with conditional ops). If primary waited for ACK from
> backup, we wouldn't save anything.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mail
configuration, we need to keep the guarantees.
>
> Radim
>
> On 11/27/2015 10:34 AM, Bela Ban wrote:
>> Adding to what Radim wrote (below), would the following make sense
>> (conditions: non-TX, P != O && O != B)?
>>
>> The lock we acquire on P is actua
ly the reliability.
Unless I'm mistaken, this is already the case: Infinispan's internal
thread pool performs ordering and delivery afair.
> R.
>
>> I don't say that these async Bs are not possible, but not in the basic
>> case - for default configuration, we need to ke
Hi Dan,
what a coincidence, I tried Chronon as well, but outside of IDEA as it
requires the commercial version and I only have the community version...
However, using something like Chronos is certainly worth looking into,
for all of us, as (as you mentioned) you only need to reproduce the
wards in time... Well, I haven't got to the
point where I enjoy it yet, but I think I made some progress :)
Cheers
Dan
On Tue, Sep 15, 2015 at 12:12 PM, Bela Ban <b...@redhat.com> wrote:
Hi Dan,
what a coincidence, I tried Chronon as well, but outside of IDEA as it
requires the commercial
improvements:
https://github.com/infinispan/infinispan/wiki/Java-8-API-proposal
It'd be great to hear your thoughts.
Proposals for Java 8 versions for cache manager, remote cache and other
external APIs are yet TBD.
Regards,
--
Galder Zamarreño
gal...@redhat.com
--
Bela Ban, JGroups lead (http
@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org
this.
Radim
[1]
https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-Infinispan
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo
://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
() and exception message could clarify the situation a bit for
beginners like me.
--
Tuomas
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org
Does Byteman allow you to use annotations as injection points ? Didn't
know that. Can you show a sample RULE ?
On 10/11/14 10:22, Radim Vansa wrote:
On 11/07/2014 02:27 PM, Bela Ban wrote:
On 07/11/14 13:45, Radim Vansa wrote:
Hijacking thread 'Remoting package refactor' as the discussion has
, do you have the document describing pros and cons of those other
AOP frameworks?
[1] http://kamon.io/
On 11/10/2014 11:05 AM, Bela Ban wrote:
Does Byteman allow you to use annotations as injection points ? Didn't
know that. Can you show a sample RULE ?
On 10/11/14 10:22, Radim Vansa wrote
.
Sanne
On 10 November 2014 10:41, Bela Ban b...@redhat.com wrote:
On 10/11/14 11:33, Radim Vansa wrote:
No way I'd be aware of (you can specify the rule directly in annotation,
but that's not what I'd like to do). Though, I don't think it would be
too complicated to implement.
But as I've
exceptions [2]).
Yes, I've also run into this before, not really nice.
Radim
[1] https://github.com/rvansa/message-flow-tracer
[2] https://issues.jboss.org/browse/BYTEMAN-237
On 11/07/2014 01:21 PM, Bela Ban wrote:
Hi Radim,
no I haven't. However, you can replace the thread pools used
://issues.jboss.org/browse/ISPN-4610 = non transactional total
order
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org
pool
I think this gives you a mixture between ease of use and flexibility in
configuring pool per cache if needed
On 06/11/14 16:23, Pedro Ruivo wrote:
On 11/06/2014 03:01 PM, Bela Ban wrote:
On 06/11/14 15:36, Pedro Ruivo wrote:
* added a single thread remote executor service
hundreds or thousands of caches and having
separate threadpool for each of them could easily drain resources. And
sharing resources is the purpose of threadpools, right?
Radim
On 11/06/2014 04:37 PM, Bela Ban wrote:
#1 I would by default have 1 thread pool shared by all caches
#2 This global
On 18/09/14 15:28, Dan Berindei wrote:
On Thu, Sep 18, 2014 at 3:09 PM, Bela Ban b...@redhat.com
mailto:b...@redhat.com wrote:
On 18/09/14 13:03, Dan Berindei wrote:
Thanks Pedro, this looks great.
However, I don't think it's ok to treat CommitCommands
)
at
org.infinispan.query.helper.TestableCluster.killAll(TestableCluster.java:94)
-- Sanne
On 10 September 2014 14:08, Bela Ban b...@redhat.com wrote:
On 10/09/14 13:58, Alan Field wrote:
Hey Bela,
Just a quick heads up. I'm currently working on
https://issues.jboss.org/browse/JGRP-1877, which it critical
to
determine the priority of this issue.
Thanks,
Alan
- Original Message -
From: Bela Ban b...@redhat.com mailto:b...@redhat.com
To: infinispan-dev@lists.jboss.org
mailto:infinispan-dev@lists.jboss.org
Sent: Wednesday, September 10, 2014 12:05
:
On Wed, Aug 6, 2014 at 6:19 PM, Bela Ban b...@redhat.com wrote:
Hey Dan,
On 06/08/14 16:13, Dan Berindei wrote:
I could create the issue in JIRA, but I wouldn't make it high
priority
because I think it have lots of corner cases with NBST and cause
headaches for the maintainers of state
overall traffic, which indirectly should lead to
better performance. I hope you wrap your work with a JIRA and commit it !
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
the agenda. I'll send out an email re dates and location
shortly.
[1] https://mojo.redhat.com/docs/DOC-977279
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org
sessions.
Implementing the state machine-based interceptor stack may give us a
performance boost, but I'm much more certain that it's a very complex,
high risk task... and we don't have a stable test suite yet :)
Yes - this is something major, let's add it to the agenda
--
Bela Ban, JGroups lead
changed the JGroups UDP
default configuration.
Sanne
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Thanks Galder, appreciated !
On 14/07/14 11:00, Galder Zamarreño wrote:
On 07 Jul 2014, at 10:14, Bela Ban b...@redhat.com wrote:
1: Observation:
-
In my Infinispan perf test (IspnPerfTest), I used
cache.getAdvancedCache().withFlags(...).put(key,value) in a tight loop.
I've
But where do I pass in my infinispan.xml config file ? I don't want a
pure programtic configuration
On 07/07/14 13:30, Mircea Markus wrote:
On Jul 7, 2014, at 11:52, Sanne Grinovero sa...@infinispan.org wrote:
On 7 July 2014 11:04, Bela Ban b...@redhat.com wrote:
How ? I already have
Makes sense; I'll try to get a jmc dump
On 07/07/14 13:36, Mircea Markus wrote:
On Jul 7, 2014, at 10:37, Bela Ban b...@redhat.com wrote:
10x faster? That's surprising for a benchmark which is supposed to be
network bound isn't it?
I ran 2 IspnPerfTest processes on my local box
configuration entirely
just because of #2
On 07/07/14 13:30, Mircea Markus wrote:
On Jul 7, 2014, at 11:52, Sanne Grinovero sa...@infinispan.org wrote:
On 7 July 2014 11:04, Bela Ban b...@redhat.com wrote:
How ? I already have an infinispan.xml, create a CacheManager off of it
and now only want
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
check out.
http://thesecretlivesofdata.com/raft/
Some other good resources.
http://thinkdistributed.io/blog/2013/07/12/consensus.html
https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf
https://github.com/mgodave/barge
--
Bela Ban, JGroups lead (http
!)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
https://www.facebook.com/HumanFishBrewery
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
No, my good friend Ales sent me that link...
On 05/03/14 16:31, Vladimir Blagojevic wrote:
+1 Are you in Slovenia?
On 3/5/2014, 10:26 AM, Bela Ban wrote:
https://www.facebook.com/HumanFishBrewery
___
infinispan-dev mailing list
infinispan-dev
for UDP and TCP only, I'm not talking about the shmem
transport.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
-transport-choices-and-ambitions-tp4028925.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban
...@redhat.com twitter.com/galderz
Project Lead, Escalante http://escalante.io
Engineer, Infinispan http://infinispan.org
___ infinispan-dev
mailing list infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban
/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
On 11/11/13 9:27 AM, Radim Vansa wrote:
On 11/08/2013 05:47 PM, Bela Ban wrote:
On 11/8/13 4:15 PM, Radim Vansa wrote:
First of all, I think that naming old, new where 3.2.7 new == 3.4.0
old sucks. Let's use some more meaningful names.
Even better: I named the latest bundler latest ha ha
Hi Mircea,
On 11/8/13 8:05 PM, Mircea Markus wrote:
On Nov 8, 2013, at 10:47 AM, Bela Ban b...@redhat.com wrote:
I think I'll ignore the DONT_BUNDLE flag on the sender's side if we have
the right bundler in place. Take a look at [1] and let me know what you
think...
[1] https
protocols are complicated as as they are :-)
On purpose; it's called job security for me !! :-)
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo
I think I'll ignore the DONT_BUNDLE flag on the sender's side if we have
the right bundler in place. Take a look at [1] and let me know what you
think...
[1] https://issues.jboss.org/browse/JGRP-1737
--
Bela Ban, JGroups lead (http://www.jgroups.org
/2013 11:47 AM, Bela Ban wrote:
I think I'll ignore the DONT_BUNDLE flag on the sender's side if we have
the right bundler in place. Take a look at [1] and let me know what you
think...
[1] https://issues.jboss.org/browse/JGRP-1737
--
Bela Ban, JGroups lead (http://www.jgroups.org
holding out for that is probably preferable.
Paul.
On 6 Nov 2013, at 07:03, Bela Ban b...@redhat.com
mailto:b...@redhat.com wrote:
There's a talk on this already on YouTube. There's also a repo [1] where
the code lives.
I'll attend, but it would be nice if someone from the Infinispan
to attend remotely?
The talk is on Tuesday the 12th November at 18:15 GMT and will be
broadcast over Google Hangouts on air.
More details here: http://bit.ly/19fc1a3
Paul.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev
On 10/31/13 4:45 PM, Dennis Reed wrote:
On 10/31/2013 02:18 AM, Bela Ban wrote:
Also if we did have read only, what criteria would cause those nodes
to be writeable again?
Once you become the primary partition, e.g. when a view is received
where view.size() = N where N is a predefined
On 10/31/13 11:20 PM, Sanne Grinovero wrote:
On 31 October 2013 20:07, Mircea Markus mmar...@redhat.com wrote:
On Oct 31, 2013, at 3:45 PM, Dennis Reed der...@redhat.com wrote:
On 10/31/2013 02:18 AM, Bela Ban wrote:
Also if we did have read only, what criteria would cause those nodes
for cluster events (wiki page)
Hi,
I've added a wiki page[1] capturing our discussions around cluster events.
Any feedback welcomed!
[1]
https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions
Cheers,
--
Bela Ban, JGroups lead (http://www.jgroups.org
/infinispan/wiki/Handling-cluster-partitions
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
Cheers,
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan
will be notified, who can then start additional nodes for the
system to acquire primary partition and become accessible again.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
On 10/31/13 1:05 PM, Mircea Markus wrote:
On Oct 31, 2013, at 7:10 AM, Bela Ban b...@redhat.com wrote:
Just to clarify, can you comment on whether the statements below are true ?
#1 When mode=repl is used, the event itself is never broadcast; it is
always local and no communication
On 10/31/13 1:23 PM, Mircea Markus wrote:
On 31 Oct 2013, at 07:18, Bela Ban b...@redhat.com wrote:
On 10/30/13 8:28 PM, William Burns wrote: Since it seems I can't
comment on the wiki itself, I am just replying here.
I wonder if the third option 'Primary partition' is desirable.
I
Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Bela Ban
Sent: Wednesday, October 16, 2013 9:50 AM
To: infinispan-dev@lists.jboss.org
Subject: Re: [infinispan-dev] The windup of 6.0.0
Hi Erik,
On 10/11/13 3:30 AM, Erik
1 - 100 of 322 matches
Mail list logo
