The nodes are on VirtualBox VMs and connected via the Virtualboxe's 'bridged'
network. Because it's Centos the each machines own firewall on must be set up
to enable the required ports (like most Unixes).
As a work round I can use static. That it works fine. However every time I
create a new m
Am trying to set up a couple of 2.5.0 nodes on CentOS boxes. I have opened the
recommended ports:
firewall-cmd --add-port=47500-47502/tcp
firewall-cmd --add-port=47100-47200/tcp
firewall-cmd --add-port=47400/udp
I see an initial UDP packet, to the ignite multicast group address, received
corre
They are separate issues. One is that the isLocalLocked() method returns
incorrect results if a remote lock is held.
The other is more serious because, as Denis has commented, it means that two
nodes can end up holding a lock at the same time.
Although, I appreciate, that if lock code is using
It appears that cache locks are intended to support re-entrancy. The debugger
shows a count variable and the lock can be taken several times by the same node
and then unlocked an equal number of times.
If a node has taken a lock several times a second node attempts to take the
same lock then, a
Additionally if a lock is held by another thread lock.tryLock() appears to
block.
Demonstrated by the following code. See header comment for a full description.
The error at line 85 should not be printed.
Found on Ignite 2.5.0. Reproducible on Windows and RHL.
Note : The test is technically ti
fe re-entrant locks still held after a node exits.
No. I see no message.
On Fri, Jun 8, 2018 at 7:27 PM, Jon Tricker
mailto:jtric...@temenos.com>> wrote:
Do you see the message "ERROR ; Lock is not released on exit" printed by the
code?
I believe if things are working corre
rant locks still held after a node exits.
Hi,
I've run your code several times and see no errors.
On Fri, Jun 8, 2018 at 12:59 PM, Jon Tricker
mailto:jtric...@temenos.com>> wrote:
Hi. I have been observing a problem on 2.5.0 where a node shuts down but locks
held by it ap
Hi. I have been observing a problem on 2.5.0 where a node shuts down but locks
held by it appear to still be held.
Hopefully the attached demo code illustrates the issues (there is a detailed
description in the files header comment).
I have searched the archives and find similar bug reported bu