August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent

by Joerg Baesner (Jira)

Joerg Baesner created WFLY-12446: ------------------------------------ Summary: Memory leak in StatelessSessionComponent Key: WFLY-12446 URL: https://issues.jboss.org/browse/WFLY-12446 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 17.0.1.Final Reporter: Joerg Baesner Assignee: Cheng Fang Attachments: playground-jee8.zip When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g. {code} One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>". {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4430) Unable to find class 'ksLoggers.newFileLogger'

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4430?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-4430. --------------------------------- Resolution: Cannot Reproduce I have no idea of how to reproduce your problem. I have seen similar problems when trying to put Drools in a fat jar and if you're doing this you can find a solution here https://docs.jboss.org/drools/release/7.25.0.Final/drools-docs/html_singl... If this is not the case please feel free to reopen this ticket and attach to it a complete reproducer of this issue. > Unable to find class 'ksLoggers.newFileLogger' > ---------------------------------------------- > > Key: DROOLS-4430 > URL: https://issues.jboss.org/browse/DROOLS-4430 > Project: Drools > Issue Type: Bug > Environment: Windows 1 w/ JDK-12.02, Eclipse > Reporter: Stephen Kaisler > Assignee: Mario Fusco > Priority: Major > Attachments: MsgreClass NotFound Exception.docx, MsgreClass NotFound Exception.docx > > > java.lang.ClassNotFoundException: Unable to find class 'ksLoggers.newFileLogger' > at org.kie.soup.project.datamodel.commons.types.ClassTypeResolver.resolveType(ClassTypeResolver.java:268) > at org.kie.soup.project.datamodel.commons.types.ClassTypeResolver.resolveType(ClassTypeResolver.java:153) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.processGlobals(KnowledgeBuilderImpl.java:1686) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.processOtherDeclarations(KnowledgeBuilderImpl.java:1668) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildOtherDeclarations(KnowledgeBuilderImpl.java:2511) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackagesWithoutRules(KnowledgeBuilderImpl.java:2458) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2449) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:108) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:100) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:261) > at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:201) > at org.drools.compiler.kie.builder.impl.AbstractKieModule.createKieBase(AbstractKieModule.java:215) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:406) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:374) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBaseFromKieSessionModel(KieContainerImpl.java:575) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:551) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:458) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:441) > at CAKnowledgeBase.CAKB.initializeRuleEngine(CAKB.java:269) > at chemistryAdvisor.ChemistryAdvisor.main(ChemistryAdvisor.java:217) > SOurce code: > try > { > // define a KieModule > //KieModuleModel CAproj = ks.newKieModuleModel(); > > // get a container for the KieBases > chemistryAdvisorSession = CAks.newKieClasspathContainer().newKieSession(); > if (debugKB) > { > System.out.println("\ninitialized KieContainer:\t" + CAContainer); > } > } > catch (NoClassDefFoundError fe) > { > fe.printStackTrace(); > } > where CAks is a KieSession. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2360) DeadLock while acqiring a distributed lock consecutively by the same thread in a loop

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2360?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2360: -------------------------------- Hi [~dklosek] Daniel, I'm afraid I don't have the time to backport this to 3.x myself. If you want to do this, then go ahead and submit a pull request! No chance of upgrading to 4.x? > 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 > Fix For: 4.1.2 > > 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.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2299: -------------------------------- Super, good to know! Now that you're using distributed locks, it's time to talk about my dislike of distributed locks, especially in light of partitions, isn't it? :-) > 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.1.2 > > Attachments: JGroupsExample.java, image.png, 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.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12436) Upgrade jboss-jsf-api_2.3_spec to 3.0.0.CR1

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFLY-12436?page=com.atlassian.jira.plugin... ] Farah Juma commented on WFLY-12436: ----------------------------------- [~soul2zimate] As mentioned on the PR, I can successfully access the artifact using both the HTTPS and HTTP URLS. Are you still seeing this issue? > Upgrade jboss-jsf-api_2.3_spec to 3.0.0.CR1 > ------------------------------------------- > > Key: WFLY-12436 > URL: https://issues.jboss.org/browse/WFLY-12436 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 18.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBEE-207) Create jboss-jakarta-annotations-api_spec fork of jakarta.annotation:jakarta.annotation-api

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/JBEE-207?page=com.atlassian.jira.plugin.s... ] Yeray Borges resolved JBEE-207. ------------------------------- Resolution: Done > Create jboss-jakarta-annotations-api_spec fork of jakarta.annotation:jakarta.annotation-api > ------------------------------------------------------------------------------------------- > > Key: JBEE-207 > URL: https://issues.jboss.org/browse/JBEE-207 > Project: JBoss Enterprise Spec APIs > Issue Type: Task > Components: jboss-annotations-api > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Major > > Create https://github.com/jboss/jboss-jakarta-annotations-api_spec fork of jakarta.annotation:jakarta.annotation-api -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBEE-206) Create jboss-jakarta-interceptors-api_spec fork of jakarta.interceptor:jakarta.interceptor-api

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/JBEE-206?page=com.atlassian.jira.plugin.s... ] Yeray Borges resolved JBEE-206. ------------------------------- Resolution: Done > Create jboss-jakarta-interceptors-api_spec fork of jakarta.interceptor:jakarta.interceptor-api > ---------------------------------------------------------------------------------------------- > > Key: JBEE-206 > URL: https://issues.jboss.org/browse/JBEE-206 > Project: JBoss Enterprise Spec APIs > Issue Type: Task > Components: jboss-interceptors-api > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Major > > Create https://github.com/jboss/jboss-jakarta-interceptors-api_spec fork of jakarta.interceptor:jakarta.interceptor-api -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12387) Upgrade org.jboss.spec.javax.annotation from 1.0.1.Final to 2.0.0.Final

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFLY-12387?page=com.atlassian.jira.plugin... ] Yeray Borges commented on WFLY-12387: ------------------------------------- [~brian.stansberry] Should not this one be resolved once we have the final release or should we use a different issue? Whatever is more comfortable, let me know. Currently, we have merged only CR1, we will get the final once Jakarta final is released, then I would update this issue with another PR including Jboss annotation final release. > Upgrade org.jboss.spec.javax.annotation from 1.0.1.Final to 2.0.0.Final > ----------------------------------------------------------------------- > > Key: WFLY-12387 > URL: https://issues.jboss.org/browse/WFLY-12387 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Critical > Fix For: 18.0.0.Beta1 > > > Upgrade Common Annotations JSR-250 to Jakarta EE > Fork: https://github.com/jboss/jboss-jakarta-annotations-api_spec > Working branch: [JBEE-207 | https://github.com/jboss/jboss-jakarta-annotations-api_spec/tree/JBEE-207] -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBEE-224) Revert Jboss Jakarta interceptors automatic bundle name to the original Jboss JavaEE interceptors api

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/JBEE-224?page=com.atlassian.jira.plugin.s... ] Yeray Borges resolved JBEE-224. ------------------------------- Resolution: Done > Revert Jboss Jakarta interceptors automatic bundle name to the original Jboss JavaEE interceptors api > ----------------------------------------------------------------------------------------------------- > > Key: JBEE-224 > URL: https://issues.jboss.org/browse/JBEE-224 > Project: JBoss Enterprise Spec APIs > Issue Type: Task > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Major > Fix For: jboss-interceptors-api_1.2_spec-2.0.0.CR2 > > > There is no name set yet for the Jakarta upstream, so, to prevent invalid modifications, revert the current JPMS name to the one used in the jboss Java EE spec -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBEE-224) Revert Jboss Jakarta interceptors automatic bundle name to the original Jboss JavaEE interceptors api

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/JBEE-224?page=com.atlassian.jira.plugin.s... ] Yeray Borges updated JBEE-224: ------------------------------ Description: There is no name set yet for the Jakarta upstream, so, to prevent invalid modifications, revert the current JPMS name to the one used in the jboss Java EE spec (was: There is no name set yet for the Jakarta upstream, so, to prevent invalid modifications, revert the current JBMPS name to the one used in the jboss Java EE spec) > Revert Jboss Jakarta interceptors automatic bundle name to the original Jboss JavaEE interceptors api > ----------------------------------------------------------------------------------------------------- > > Key: JBEE-224 > URL: https://issues.jboss.org/browse/JBEE-224 > Project: JBoss Enterprise Spec APIs > Issue Type: Task > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Major > Fix For: jboss-interceptors-api_1.2_spec-2.0.0.CR2 > > > There is no name set yet for the Jakarta upstream, so, to prevent invalid modifications, revert the current JPMS name to the one used in the jboss Java EE spec -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2019