[JBoss JIRA] (JGRP-2332) Port of JGroups to Quarkus
by Sanne Grinovero (Jira)
[ https://issues.jboss.org/browse/JGRP-2332?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on JGRP-2332:
---------------------------------------
I've sent a PR to Graal to resolve one of the issues:
- https://github.com/oracle/graal/pull/1088
> Port of JGroups to Quarkus
> --------------------------
>
> Key: JGRP-2332
> URL: https://issues.jboss.org/browse/JGRP-2332
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.20
>
>
> Port JGroups to Quarkus [1].
> This is a quick and dirty port, to see what needs to be done.
> The goal is to identify changes which can be ported back to JGroups proper to make this port as easy as possible.
> Example: since JMX is not supported, separate JMX into a set of interfaces and 2 implementations: the default impl which is used when JGroups runs on a regular JVM, and another one used when run on GraalVM.
> This is currently scheduled for 4.x, but may as well end up being done in 5.x
> [1] https://quarkus.io
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by David White (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
David White edited comment on JGRP-2299 at 3/19/19 6:15 PM:
------------------------------------------------------------
compareTo just needs a null check?
was (Author: dwhitejazz):
Introduced here:
https://issues.jboss.org/browse/JGRP-1886
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.20
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by David White (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
David White commented on JGRP-2299:
-----------------------------------
Introduced here:
https://issues.jboss.org/browse/JGRP-1886
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.20
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by David White (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
David White commented on JGRP-2299:
-----------------------------------
public int compareTo(Owner o) {
return thread_id < o.thread_id? -1 : thread_id > o.thread_id? 1 : address.compareTo(o.address);
}
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.20
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by David White (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
David White commented on JGRP-2299:
-----------------------------------
Version 4.0.9 did not have the compare method, so it seems to be ok there.
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.20
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by David White (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
David White commented on JGRP-2299:
-----------------------------------
We are seeing a similar issue in version 4.0.19. We are testing with multiple threads attempting to lock on a single resource. During the unlock operation we sometimes get a NullPointerException and we cannot figure out where this is coming from.
[591:Thread-557] [2019-03-19 17:31:51.181] ERROR java.lang.NullPointerException
org.jgroups.util.Owner.compareTo(Owner.java:56)
org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:1141)
org.jgroups.protocols.Locking$ClientLock.compareTo(Locking.java:941)
java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:666)
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:910)
java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1990)
java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:252)
org.jgroups.protocols.Locking$ClientLockTable.addToPendingReleaseRequests(Locking.java:1302)
org.jgroups.protocols.Locking$ClientLock._unlock(Locking.java:1069)
org.jgroups.protocols.Locking$ClientLock.unlock(Locking.java:995)
org.jgroups.protocols.Locking.down(Locking.java:175)
org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:908)
org.jgroups.JChannel.down(JChannel.java:668)
org.jgroups.blocks.locking.LockService$LockImpl.unlock(LockService.java:167)
...
I'm not sure what version of JGroups introduced this issue. It did not happen in a very old version of JGroups, 3.4.0.Alpha2.
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.20
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4377) Support passing properties and environment variables to the Windows server.bat
by James Perkins (Jira)
James Perkins created WFCORE-4377:
-------------------------------------
Summary: Support passing properties and environment variables to the Windows server.bat
Key: WFCORE-4377
URL: https://issues.jboss.org/browse/WFCORE-4377
Project: WildFly Core
Issue Type: Enhancement
Components: Scripts
Reporter: James Perkins
Assignee: James Perkins
Script is missing few features, which WildFly/Commons Daemon provide:
# it is not possible to pass properties file to WildFly instance
# it is not possible to pass environment variables to WildFly instance(more concretely - {{JBOSS_MODULEPATH}} to specify one or more external module directories)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-3891) Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-3891?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3891:
---------------------------------------
We could do that. Maybe something as simple as {{$handlerName + "wfcore-pattern-formatter"}}. I highly doubt anyone would create a name like that :)
> Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3891
> URL: https://issues.jboss.org/browse/WFCORE-3891
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Nikoleta Žiaková
> Assignee: James Perkins
> Priority: Major
>
> When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> The same scenario works for e.g. {{pattern-formatter}}:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months