[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-944?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFCORE-944:
-------------------------------
Fix Version/s: 10.0.0.Beta2
(was: 10.0.0.Beta1)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.jboss.org/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFCORE-4407) Cannot configure Elytron security domain using embedded server in admin mode
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-4407?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-4407:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3729, https://github.com/wildfly/wildfly-core/pull/3861 (was: https://github.com/wildfly/wildfly-core/pull/3729)
> Cannot configure Elytron security domain using embedded server in admin mode
> ----------------------------------------------------------------------------
>
> Key: WFCORE-4407
> URL: https://issues.jboss.org/browse/WFCORE-4407
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded
> Environment:
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> There are some configurations that are impossible to do using the embedded server, for example, we cannot create a security domain in Elytron that references a security domain in the security subsystem:
> {noformat}
> embed-server --server-config=standalone-full-ha.xml --std-out=echo
> /subsystem=security/security-domain=my-sec-domain:add(cache-type=default)
> /subsystem=security/security-domain=my-sec-domain/authentication=classic:add(login-modules=[{code=RealmUsersRoles, flag=required, module=RealmUsersRoles, module-options=[("usersProperties"=>"usersProperties"),("rolesProperties"=>"rolesProperties")]}])
> /subsystem=security/elytron-realm=my-sec-domain:add(legacy-jaas-config=my-sec-domain)
> /subsystem=elytron/security-domain=my-sec-domain:add(realms=[{realm=my-sec-domain}],default-realm=my-sec-domain,permission-mapper=default-permission-mapper)
> stop-embedded-server
> {noformat}
> The execution of these operations in an embedded server running in admin-mode throws the following error:
> {noformat}
> [standalone@embedded /] /subsystem=elytron/security-domain=my-sec-domain:add(realms=[{realm=my-sec-domain}],default-realm=my-sec-domain,permission-mapper=default-permission-mapper)
> 12:30:53,429 ERROR [org.jboss.as.controller.management-operation] (pool-3-thread-1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "my-sec-domain")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.my-sec-domain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.my-sec-domain.initial is missing [org.wildfly.security.security-realm.my-sec-domain]"]
> }
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.my-sec-domain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.my-sec-domain.initial is missing [org.wildfly.security.security-realm.my-sec-domain]"]
> },
> "rolled-back" => true
> }
> {noformat}
> The problem here is Elytron security domain services cannot be up because they require the legacy installed realm services, which are not up when we are using embedded in admin-only mode.
> The SecurityDomain advertises no runtime operation, if no services are installed that would ever depend on security domain we may be able to skip installing some of these services entirely and allow their configuration in embedded / admin-only.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFCORE-4407) Cannot configure Elytron security domain using embedded server in admin mode
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4407?page=com.atlassian.jira.plugi... ]
Jeff Mesnil reopened WFCORE-4407:
---------------------------------
> Cannot configure Elytron security domain using embedded server in admin mode
> ----------------------------------------------------------------------------
>
> Key: WFCORE-4407
> URL: https://issues.jboss.org/browse/WFCORE-4407
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded
> Environment:
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> There are some configurations that are impossible to do using the embedded server, for example, we cannot create a security domain in Elytron that references a security domain in the security subsystem:
> {noformat}
> embed-server --server-config=standalone-full-ha.xml --std-out=echo
> /subsystem=security/security-domain=my-sec-domain:add(cache-type=default)
> /subsystem=security/security-domain=my-sec-domain/authentication=classic:add(login-modules=[{code=RealmUsersRoles, flag=required, module=RealmUsersRoles, module-options=[("usersProperties"=>"usersProperties"),("rolesProperties"=>"rolesProperties")]}])
> /subsystem=security/elytron-realm=my-sec-domain:add(legacy-jaas-config=my-sec-domain)
> /subsystem=elytron/security-domain=my-sec-domain:add(realms=[{realm=my-sec-domain}],default-realm=my-sec-domain,permission-mapper=default-permission-mapper)
> stop-embedded-server
> {noformat}
> The execution of these operations in an embedded server running in admin-mode throws the following error:
> {noformat}
> [standalone@embedded /] /subsystem=elytron/security-domain=my-sec-domain:add(realms=[{realm=my-sec-domain}],default-realm=my-sec-domain,permission-mapper=default-permission-mapper)
> 12:30:53,429 ERROR [org.jboss.as.controller.management-operation] (pool-3-thread-1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "my-sec-domain")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.my-sec-domain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.my-sec-domain.initial is missing [org.wildfly.security.security-realm.my-sec-domain]"]
> }
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.my-sec-domain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.my-sec-domain.initial is missing [org.wildfly.security.security-realm.my-sec-domain]"]
> },
> "rolled-back" => true
> }
> {noformat}
> The problem here is Elytron security domain services cannot be up because they require the legacy installed realm services, which are not up when we are using embedded in admin-only mode.
> The SecurityDomain advertises no runtime operation, if no services are installed that would ever depend on security domain we may be able to skip installing some of these services entirely and allow their configuration in embedded / admin-only.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFCORE-4407) Cannot configure Elytron security domain using embedded server in admin mode
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4407?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4407:
--------------------------------
Fix Version/s: 10.0.0.Beta2
(was: 9.0.0.Beta7)
(was: 9.0.0.Final)
> Cannot configure Elytron security domain using embedded server in admin mode
> ----------------------------------------------------------------------------
>
> Key: WFCORE-4407
> URL: https://issues.jboss.org/browse/WFCORE-4407
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded
> Environment:
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> There are some configurations that are impossible to do using the embedded server, for example, we cannot create a security domain in Elytron that references a security domain in the security subsystem:
> {noformat}
> embed-server --server-config=standalone-full-ha.xml --std-out=echo
> /subsystem=security/security-domain=my-sec-domain:add(cache-type=default)
> /subsystem=security/security-domain=my-sec-domain/authentication=classic:add(login-modules=[{code=RealmUsersRoles, flag=required, module=RealmUsersRoles, module-options=[("usersProperties"=>"usersProperties"),("rolesProperties"=>"rolesProperties")]}])
> /subsystem=security/elytron-realm=my-sec-domain:add(legacy-jaas-config=my-sec-domain)
> /subsystem=elytron/security-domain=my-sec-domain:add(realms=[{realm=my-sec-domain}],default-realm=my-sec-domain,permission-mapper=default-permission-mapper)
> stop-embedded-server
> {noformat}
> The execution of these operations in an embedded server running in admin-mode throws the following error:
> {noformat}
> [standalone@embedded /] /subsystem=elytron/security-domain=my-sec-domain:add(realms=[{realm=my-sec-domain}],default-realm=my-sec-domain,permission-mapper=default-permission-mapper)
> 12:30:53,429 ERROR [org.jboss.as.controller.management-operation] (pool-3-thread-1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "my-sec-domain")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.my-sec-domain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.my-sec-domain.initial is missing [org.wildfly.security.security-realm.my-sec-domain]"]
> }
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.my-sec-domain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.my-sec-domain.initial is missing [org.wildfly.security.security-realm.my-sec-domain]"]
> },
> "rolled-back" => true
> }
> {noformat}
> The problem here is Elytron security domain services cannot be up because they require the legacy installed realm services, which are not up when we are using embedded in admin-only mode.
> The SecurityDomain advertises no runtime operation, if no services are installed that would ever depend on security domain we may be able to skip installing some of these services entirely and allow their configuration in embedded / admin-only.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JGRP-2360) DeadLock while acqiring a distributed lock consecutively by the same thread in a loop
by Daniel Klosinski (Jira)
[ https://issues.jboss.org/browse/JGRP-2360?page=com.atlassian.jira.plugin.... ]
Daniel Klosinski updated JGRP-2360:
-----------------------------------
Description:
Deadlock intermittently happens when trying to acquire a distributed lock by the same VM, consecutively by the same thread in a loop. Here is a code snippet for which this issue can occur :
{code}
for(String s : list){
Lock lock=lock_service.getLock("test_lock_name");
lock.lock();
//perform bussines logic
lock.unlock();
}
{code}
Running such loop I am getting dead look after a few loop iterations. In the attached logs program hanged after 3 iterations
During the troubleshooting, I found out that lock_id is not being incremented for the new distributed lock. In the first two loop iterations everything was fine. At the third iteration lock_id didn't get increased:
{code}
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: RELEASE_LOCK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: RELEASE_LOCK_OK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: RELEASE_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: RELEASE_LOCK_OK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: CREATE_LOCK[test_lock_name, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
{code}
I've added few extra loggers into Jgroups-4.1.1.Final code and I realized that the second client lock was not removed from the client lock table before the creation of 3rd client lock. The issue lays in below piece of code. Owner consists of address and threadID. If the same thread, on the same VM, creates distributed lock consecutively and if there is an existing entry in the client lock table for the same owner, the new lock won't be created. The old client lock will be used to acquire a new distributed lock :
{code}
protected synchronized ClientLock getLock(String name, Owner owner, boolean create_if_absent) {
Map<Owner,ClientLock> owners=table.get(name);
if(owners == null) {
if(!create_if_absent)
return null;
owners=Util.createConcurrentMap(20);
Map<Owner,ClientLock> existing=table.putIfAbsent(name,owners);
if(existing != null)
owners=existing;
}
ClientLock lock=owners.get(owner);
if(lock == null) {
if(!create_if_absent)
return null;
lock=createLock(name, owner);
owners.put(owner, lock);
}
return lock;
}
{code}
I believe that this issue was introduced by the fix for JGRP-2234 and it is caused by the race condition. The logic that deletes client lock from the client lock table is now executed when the client's VM receives RELEASE_LOCK_OK message from the coordinator. Previously this deletion was executed by the thread in which unlock() method was called. Now, it is executed by the separate thread which handles RELEASE_LOCK_OK from the coordinator and this is why we have a race condition here. Here is a sequence which leads to deadlock:
1. Create client lock (lock_id=2)
2. Send GRANT_LOCK (lock_id=2) to coordinator
3. Receive LOCK_GRANTED (lock_id=2) from coordinator
4. Send RELEASE_LOCK (lock_id=2) to coordinator
5. Call look() method in the same thread (new client lock won't be created as there is an existing entry in the client lock table for this owner)
6. Receive RELEASE_LOCK_OK and delete client lock from client lock table.
7. Send GRANT_LOCK (lock_id=2) to coordinator
8. Receive LOCK_GRANTED (lock_id=2) from coordinator
9. No entry in the client lock table. It's not possible to get the thread which needs to be notified.
I am attaching a simple program which can be used to reproduce and generated logs.
was:
Deadlock intermittently happens when trying to acquire a distributed lock by the same VM, consecutively by the same thread in a loop. Here is a code snippet for which this issue can occur :
{code}
for(String s : list){
Lock lock=lock_service.getLock("test_lock_name");
lock.lock();
//perform bussines logic
lock.unlock();
}
{code}
During the troubleshooting, I found out that lock_id is not being incremented for the new distributed lock. In the first two loop iterations everything was fine. At the third iteration lock_id didn't get increased:
{code}
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: RELEASE_LOCK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: RELEASE_LOCK_OK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: RELEASE_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: RELEASE_LOCK_OK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: CREATE_LOCK[test_lock_name, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
{code}
I've added few extra loggers into Jgroups-4.1.1.Final code and I realized that the second client lock was not removed from the client lock table before the creation of 3rd client lock. The issue lays in below piece of code. Owner consists of address and threadID. If the same thread, on the same VM, creates distributed lock consecutively and if there is an existing entry in the client lock table for the same owner, the new lock won't be created. The old client lock will be used to acquire a new distributed lock :
{code}
protected synchronized ClientLock getLock(String name, Owner owner, boolean create_if_absent) {
Map<Owner,ClientLock> owners=table.get(name);
if(owners == null) {
if(!create_if_absent)
return null;
owners=Util.createConcurrentMap(20);
Map<Owner,ClientLock> existing=table.putIfAbsent(name,owners);
if(existing != null)
owners=existing;
}
ClientLock lock=owners.get(owner);
if(lock == null) {
if(!create_if_absent)
return null;
lock=createLock(name, owner);
owners.put(owner, lock);
}
return lock;
}
{code}
I believe that this issue was introduced by the fix for JGRP-2234 and it is caused by the race condition. The logic that deletes client lock from the client lock table is now executed when the client's VM receives RELEASE_LOCK_OK message from the coordinator. Previously this deletion was executed by the thread in which unlock() method was called. Now, it is executed by the separate thread wich handles RELEASE_LOCK_OK from the coordinator and this is why we have a care condition here.
I am attaching a simple program which can be used to reproduce and generated logs.
> DeadLock while acqiring a distributed lock consecutively by the same thread in a loop
> -------------------------------------------------------------------------------------
>
> Key: JGRP-2360
> URL: https://issues.jboss.org/browse/JGRP-2360
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.18, 4.1.1
> Environment: JGroups-4.1.1-Final
> Red Hat 4.4.7-23
> JDK 1.8.0_202
> Reporter: Daniel Klosinski
> Assignee: Bela Ban
> Priority: Major
> Attachments: DLTest.java, DistributedLockRepoducer.zip, log.log
>
>
> Deadlock intermittently happens when trying to acquire a distributed lock by the same VM, consecutively by the same thread in a loop. Here is a code snippet for which this issue can occur :
> {code}
> for(String s : list){
> Lock lock=lock_service.getLock("test_lock_name");
> lock.lock();
> //perform bussines logic
> lock.unlock();
> }
> {code}
> Running such loop I am getting dead look after a few loop iterations. In the attached logs program hanged after 3 iterations
> During the troubleshooting, I found out that lock_id is not being incremented for the new distributed lock. In the first two loop iterations everything was fine. At the third iteration lock_id didn't get increased:
> {code}
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: RELEASE_LOCK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: RELEASE_LOCK_OK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: RELEASE_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: RELEASE_LOCK_OK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: CREATE_LOCK[test_lock_name, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> {code}
> I've added few extra loggers into Jgroups-4.1.1.Final code and I realized that the second client lock was not removed from the client lock table before the creation of 3rd client lock. The issue lays in below piece of code. Owner consists of address and threadID. If the same thread, on the same VM, creates distributed lock consecutively and if there is an existing entry in the client lock table for the same owner, the new lock won't be created. The old client lock will be used to acquire a new distributed lock :
> {code}
> protected synchronized ClientLock getLock(String name, Owner owner, boolean create_if_absent) {
> Map<Owner,ClientLock> owners=table.get(name);
> if(owners == null) {
> if(!create_if_absent)
> return null;
> owners=Util.createConcurrentMap(20);
> Map<Owner,ClientLock> existing=table.putIfAbsent(name,owners);
> if(existing != null)
> owners=existing;
> }
> ClientLock lock=owners.get(owner);
> if(lock == null) {
> if(!create_if_absent)
> return null;
> lock=createLock(name, owner);
> owners.put(owner, lock);
> }
> return lock;
> }
> {code}
> I believe that this issue was introduced by the fix for JGRP-2234 and it is caused by the race condition. The logic that deletes client lock from the client lock table is now executed when the client's VM receives RELEASE_LOCK_OK message from the coordinator. Previously this deletion was executed by the thread in which unlock() method was called. Now, it is executed by the separate thread which handles RELEASE_LOCK_OK from the coordinator and this is why we have a race condition here. Here is a sequence which leads to deadlock:
> 1. Create client lock (lock_id=2)
> 2. Send GRANT_LOCK (lock_id=2) to coordinator
> 3. Receive LOCK_GRANTED (lock_id=2) from coordinator
> 4. Send RELEASE_LOCK (lock_id=2) to coordinator
> 5. Call look() method in the same thread (new client lock won't be created as there is an existing entry in the client lock table for this owner)
> 6. Receive RELEASE_LOCK_OK and delete client lock from client lock table.
> 7. Send GRANT_LOCK (lock_id=2) to coordinator
> 8. Receive LOCK_GRANTED (lock_id=2) from coordinator
> 9. No entry in the client lock table. It's not possible to get the thread which needs to be notified.
> I am attaching a simple program which can be used to reproduce and generated logs.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-12287) Remove transitive org.slf4j:jcl-over-slf4j:jar from dependency tree and include org.slf4j:slf4j-log4j12:jar when using org.wildfly:wildfly-jaxws-client-bom as direct a dependency
by Fabio Burzigotti (Jira)
[ https://issues.jboss.org/browse/WFLY-12287?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti commented on WFLY-12287:
-----------------------------------------
[~jamezp], agree on slf4j-api just representing a facade, but in this very case the slf4j-log4j12 artifact is a dependency of jbossws-cxf-client which in turn is pulled in by the client BOM definition. So, basically, the BOM generation seems to be overriding a (clientside) artifact level inclusion.
[~emmartins], regarding the jcl-over-slf4j dependency, that is as well a BOM generation side effect: it is not banned from the server definition but it is excluded at component level (jbossws-cxf).
[~emmartins], what you state about introducing manually maintained BOM configuration makes sense too, so agreeing with [~jbliznak] here, and probably we also need to document that existing projects POMs could need some kind of adjustment as dep tree is going to change when using the Wildfly JAXWS Client BOM.
WDYT?
> Remove transitive org.slf4j:jcl-over-slf4j:jar from dependency tree and include org.slf4j:slf4j-log4j12:jar when using org.wildfly:wildfly-jaxws-client-bom as direct a dependency
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12287
> URL: https://issues.jboss.org/browse/WFLY-12287
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts, Web Services
> Affects Versions: 17.0.1.Final
> Reporter: Fabio Burzigotti
> Assignee: Eduardo Martins
> Priority: Major
>
> When using Wildfly JAXWS Client BOM an unwanted reference to org.slf4j:jcl-over-slf4j:jar appears in the dependency tree even it is explicitly excluded by org.jboss.ws.cxf:jbossws-cxf POM. Instead there's no reference to org.slf4j:slf4j-log4j12:jar while it seems it's needed by org.jboss.ws.cxf:jbossws-cxf-client:jar
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-6892) Access logging for EJBs
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-6892?page=com.atlassian.jira.plugin.... ]
Cheng Fang updated WFLY-6892:
-----------------------------
Fix Version/s: 18.0.0.Beta1
> Access logging for EJBs
> -----------------------
>
> Key: WFLY-6892
> URL: https://issues.jboss.org/browse/WFLY-6892
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Cheng Fang
> Priority: Major
> Labels: affects-model, affects_elytron
> Fix For: 18.0.0.Beta1
>
>
> Access logging for EJB requests similar to Web access logging would be very useful.
> Possibly something like:
> {code}
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] [invocation id] Request Received ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Starting Invocation ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Finished Invocation ...
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years