On 7 Feb 2013, at 03:33, Navin Surtani nsurt...@redhat.com wrote:
How about Hopocalypse?
That's a real tongue twister. Try saying that a few times fast. :)
http://beeradvocate.com/beer/profile/3835/46649/?ba=kaseydad
--Navin
- Original Message -
From: Zdeněk Henek
So... you don't want to ladies teachers in nursery using Infinispan code name
for kid-word-games? :(
- Original Message -
From: Manik Surtani msurt...@redhat.com
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Thursday, February 7, 2013 10:50:34 AM
Subject: Re:
On Thu, Feb 7, 2013 at 6:53 AM, Bela Ban b...@redhat.com wrote:
Hi Pedro,
this is almost exactly what I wanted to implement !
Question:
- In RequestCorrelator.handleRequest():
protected void handleRequest(Message req, Header hdr) {
Object retval;
boolean threwException = false;
I've created https://issues.jboss.org/browse/ISPN-2805
On Wed, Feb 6, 2013 at 7:26 PM, Bela Ban b...@redhat.com wrote:
Connection reaping may lead to message loss in UNICAST{2}. Until I've
fixed [1], could you disable connection reaping ? Instructions are in [1].
[1]
Hi all,
I'm back with a more food for thought wrt JSR-107 impl. Our CacheManager
adapter needs to implement:
UserTransaction getUserTransaction();
The problem there is that there's no standard way of getting a UserTransaction
given a JTA TransactionManager.
It really is down to each
On 7 Feb 2013, at 10:30, Bela Ban b...@redhat.com wrote:
No, this *could* be in Infinispan 5.3 (it will be in JGroups 3.3).
A MessageDispatcher (RpcDispatcher) instance picks which dispatching
mechanism it wants to use. I have RequestHandler (the default) and a
sub-interface
I meant to say that this is up to you guys to decide inwhich Infinispan
release this will be used, but it will be available in JGroups 3.3.
What's the strategy/schedule for 6 and 5.3 anyway ?
On 2/7/13 11:30 AM, Bela Ban wrote:
No, this *could* be in Infinispan 5.3 (it will be in JGroups 3.3).
Hi Bela
On 2/7/13 4:53 AM, Bela Ban wrote:
Hi Pedro,
this is almost exactly what I wanted to implement !
Question:
- In RequestCorrelator.handleRequest():
protected void handleRequest(Message req, Header hdr) {
Object retval;
boolean threwException = false;
MessageRequest
On 7 Feb 2013, at 11:23, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
I'm back with a more food for thought wrt JSR-107 impl. Our CacheManager
adapter needs to implement:
UserTransaction getUserTransaction();
The problem there is that there's no standard way of getting a
On Feb 7, 2013, at 12:31 PM, Manik Surtani msurt...@redhat.com wrote:
On 7 Feb 2013, at 11:23, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
I'm back with a more food for thought wrt JSR-107 impl. Our CacheManager
adapter needs to implement:
UserTransaction
On 2/7/13 12:29 PM, Pedro Ruivo wrote:
Hi Bela
On 2/7/13 4:53 AM, Bela Ban wrote:
Hi Pedro,
this is almost exactly what I wanted to implement !
Question:
- In RequestCorrelator.handleRequest():
protected void handleRequest(Message req, Header hdr) {
Object retval;
boolean
Ok. Then a separate Lookup is what we'd need, I guess. Not pretty, but oh
well.
On 7 Feb 2013, at 11:41, Galder Zamarreño gal...@redhat.com wrote:
On Feb 7, 2013, at 12:31 PM, Manik Surtani msurt...@redhat.com wrote:
On 7 Feb 2013, at 11:23, Galder Zamarreño gal...@redhat.com wrote:
On Thu, Feb 7, 2013 at 12:43 PM, Bela Ban b...@redhat.com wrote:
On 2/7/13 11:09 AM, Dan Berindei wrote:
A few changes I have in mind (need to think about it more):
- I want to leave the existing RequestHandler interface in place, so
current implementation continue to
On 2/7/13 1:38 PM, Dan Berindei wrote:
No, I think it'll apply to all messages. A simple implementation could
dispatch OOB messages to the thread pool, as they don't need to be
ordered. Regular messages could be added to a queue where they are
processed sequentially by a
On 2/7/13 12:36 PM, Manik Surtani wrote:
On 7 Feb 2013, at 11:29, Bela Ban b...@redhat.com wrote:
I meant to say that this is up to you guys to decide inwhich Infinispan
release this will be used, but it will be available in JGroups 3.3.
What's the strategy/schedule for 6 and 5.3 anyway ?
Do we really need to expose the TransactionManager's UserTransaction
implementation?
Looking at the interface, it seems like a subset of TransactionManager, so
couldn't we return a custom UserTransaction that just delegates to the
TransactionManager?
On Thu, Feb 7, 2013 at 2:06 PM, Manik
On 1 Feb 2013, at 08:04, Radim Vansa wrote:
Hi guys,
after dealing with the large cluster for a while I find the way how we use
OOB threads in synchronous configuration non-robust.
Imagine a situation where node which is not an owner of the key calls PUT.
Then the a RPC is called to the
On 1 Feb 2013, at 09:54, Dan Berindei wrote:
Yeah, I wouldn't call this a simple solution...
The distribution/replication interceptors are quite high in the interceptor
stack, so we'd have to save the state of the interceptor stack (basically the
thread's stack) somehow and resume
Hi,
I'm working in a way to rebase auto-placer on top of NBST and I have one
question...
If you have already forgot, auto-placer analyzes the workload and tries
to move the most remote accessed keys to the corresponding requester.
After calculating the new mappings, I want to trigger the NBST
On Thu, Feb 7, 2013 at 8:05 PM, Mircea Markus mmar...@redhat.com wrote:
On 1 Feb 2013, at 09:54, Dan Berindei wrote:
Yeah, I wouldn't call this a simple solution...
The distribution/replication interceptors are quite high in the
interceptor stack, so we'd have to save the state of the
20 matches
Mail list logo
