On 09/19/2014 11:57 AM, Mircea Markus wrote:
Read Command : No changes are made. When a read command is delivered, it is
processed directly in the JGroups executor service.
- you might want to check if here's a force write lock flag present as well
No need. I double check and the get sends
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
On 09/18/2014 05:32 PM, Dan Berindei wrote:
You're right about the remote executor getting full as well, we're
lacking any feedback mechanism to tell the sender to slow down, except
for blocking the OOB thread. I wonder if we could tell JGroups somehow
to discard
Read Command : No changes are made. When a read command is delivered, it is
processed directly in the JGroups executor service.
- you might want to check if here's a force write lock flag present as well
On Sep 17, 2014, at 19:17, Pedro Ruivo pe...@infinispan.org wrote:
new link:
Thanks Pedro, this looks great.
However, I don't think it's ok to treat CommitCommands/Pessimistic
PrepareCommands as RemoteLockCommands just because they may send L1
invalidation commands. It's true that those commands will block, but
there's no need to wait for any other command before doing
On Thu, Sep 18, 2014 at 3:29 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 09/18/2014 12:03 PM, Dan Berindei wrote:
Thanks Pedro, this looks great.
However, I don't think it's ok to treat CommitCommands/Pessimistic
PrepareCommands as RemoteLockCommands just because they may send L1
new link:
https://github.com/infinispan/infinispan/wiki/Remote-Command-Handler
On 09/17/2014 05:08 PM, Pedro Ruivo wrote:
Hi,
I've just wrote on the wiki a new algorithm to better handle the remote
commands. You can find it in [1].
If you have questions, suggestion or just want to discuss
