January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2009) TCP/TCP_NIO: make SO_REUSEADDR configurable

by Bela Ban (JIRA)

Bela Ban created JGRP-2009: ------------------------------ Summary: TCP/TCP_NIO: make SO_REUSEADDR configurable Key: JGRP-2009 URL: https://issues.jboss.org/browse/JGRP-2009 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.8, 4.0 Before binding a {{ServerSocket}} or {{ServerSocketChannel}}, let the user configure whether of not to reuse addresses by setting option {{SO_REUSEADDR}} (and possibly {{SO_REUSEPORT}}?). See https://issues.jboss.org/browse/ISPN-6099 for details -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2008) Remove MuxRpcDispatcher

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2008?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2008. ---------------------------- Resolution: Done > Remove MuxRpcDispatcher > ----------------------- > > Key: JGRP-2008 > URL: https://issues.jboss.org/browse/JGRP-2008 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Can be replaced by using fork stacks -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2008) Remove MuxRpcDispatcher

by Bela Ban (JIRA)

Bela Ban created JGRP-2008: ------------------------------ Summary: Remove MuxRpcDispatcher Key: JGRP-2008 URL: https://issues.jboss.org/browse/JGRP-2008 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Can be replaced by using fork stacks -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6015) Testing JDBC connection is causing it to be created

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-6015?page=com.atlassian.jira.plugin.... ] Heiko Braun resolved WFLY-6015. ------------------------------- Fix Version/s: 10.0.0.Final Resolution: Done > Testing JDBC connection is causing it to be created > --------------------------------------------------- > > Key: WFLY-6015 > URL: https://issues.jboss.org/browse/WFLY-6015 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 10.0.0.CR5 > Environment: Mac OS X El Captain with latest update > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > MariaDB - with MariaDB JDBC driver deployed > Reporter: Renann Prado > Assignee: Harald Pehl > Fix For: 10.0.0.Final > > > Testing JDBC connection is causing it to be created. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1334) Allow disabling audit log rotation

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1334?page=com.atlassian.jira.plugi... ] Tomas Hofman edited comment on WFCORE-1334 at 1/29/16 3:06 AM: --------------------------------------------------------------- Sure, here: https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd6... was (Author: thofman): https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd6... > Allow disabling audit log rotation > ---------------------------------- > > Key: WFCORE-1334 > URL: https://issues.jboss.org/browse/WFCORE-1334 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Affects Versions: 2.0.7.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > https://bugzilla.redhat.com/show_bug.cgi?id=1301554 > org.jboss.as.controller.audit.FileAuditLogHandler always rotates audit-log.log at startup/reload. An option to disable log rotation is necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1046) Threads blocking during ReteWorkingMemory initialization of facts

by Akshay Gehi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1046?page=com.atlassian.jira.plugi... ] Akshay Gehi updated DROOLS-1046: -------------------------------- Steps to Reproduce: Create a drools file with the following condition: {noformat} rule "slowWhenCondition" when eval(mySlowCondition(fact)) then end {noformat} Create a StatefulSession and fire all the rules from multiple threads. Observe the threads in Blocking state using JVisualVM or Stack Trace. was: Create a drools file with the following condition: rule "slowWhenCondition" when eval(mySlowConditionFromDatabase(fact)) then end Create a StatefulSession and fire all the rules from multiple threads. Observe the threads in Blocking state using JVisualVM or Stack Trace. > Threads blocking during ReteWorkingMemory initialization of facts > ----------------------------------------------------------------- > > Key: DROOLS-1046 > URL: https://issues.jboss.org/browse/DROOLS-1046 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Akshay Gehi > Assignee: Mario Fusco > > While initializing facts for the first time the following method in ReteWorkingMemory is invoked: > {code:java} > private final Integer syncLock = 42; > public void initInitialFact() { > if ( initialFactHandle == null ) { > synchronized ( syncLock ) { > if ( initialFactHandle == null ) { > // double check, inside of sync point incase some other thread beat us to it. > initInitialFact(kBase, null); > } > } > } > } > {code} > Since the synchronized lock is taken on a Integer constant variable, the same object gets used across different threads. This causes the initialization of all the ReteMemoryObjects to wait in the initInitialFact() method across different threads. > The lock should be taken on Object lock = new Object() instead -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1334) Allow disabling audit log rotation

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1334?page=com.atlassian.jira.plugi... ] Tomas Hofman commented on WFCORE-1334: -------------------------------------- https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd6... > Allow disabling audit log rotation > ---------------------------------- > > Key: WFCORE-1334 > URL: https://issues.jboss.org/browse/WFCORE-1334 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Affects Versions: 2.0.7.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > https://bugzilla.redhat.com/show_bug.cgi?id=1301554 > org.jboss.as.controller.audit.FileAuditLogHandler always rotates audit-log.log at startup/reload. An option to disable log rotation is necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-2387: ------------------------------------ [~alxs] I see. So your workaround is not used for JPA entity listeners at all. Nevertheless, thanks a lot for a good tip! ;-) > CDI injection in entity listeners failing > ----------------------------------------- > > Key: WFLY-2387 > URL: https://issues.jboss.org/browse/WFLY-2387 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Class Loading, JPA / Hibernate > Affects Versions: 8.0.0.Beta1 > Reporter: Emond Papegaaij > Assignee: Scott Marlow > Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml > > > When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception: > {code} > 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25] > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3] > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75) > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128) > at org.jboss.weld.Container.instance(Container.java:65) > at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71) > at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150) > at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847) > at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846) > at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) > ... 8 more > {code} > I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1046) Threads blocking during ReteWorkingMemory initialization of facts

by Akshay Gehi (JIRA)

Akshay Gehi created DROOLS-1046: ----------------------------------- Summary: Threads blocking during ReteWorkingMemory initialization of facts Key: DROOLS-1046 URL: https://issues.jboss.org/browse/DROOLS-1046 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.3.0.Final Reporter: Akshay Gehi Assignee: Mario Fusco While initializing facts for the first time the following method in ReteWorkingMemory is invoked: {code:java} private final Integer syncLock = 42; public void initInitialFact() { if ( initialFactHandle == null ) { synchronized ( syncLock ) { if ( initialFactHandle == null ) { // double check, inside of sync point incase some other thread beat us to it. initInitialFact(kBase, null); } } } } {code} Since the synchronized lock is taken on a Integer constant variable, the same object gets used across different threads. This causes the initialization of all the ReteMemoryObjects to wait in the initInitialFact() method across different threads. The lock should be taken on Object lock = new Object() instead -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6091) Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6091: ------------------------------------ Summary: Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final Key: WFLY-6091 URL: https://issues.jboss.org/browse/WFLY-6091 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Stuart Douglas Assignee: Paul Ferraro The upgrade to Undertow 1.3.16.Final causes this test to fail frequently (but not every time). The change that makes this more frequent was the change to send the response before closing the session. If you are having trouble reproducing this you can add the following code to the bottom of the SessionOperationServlet doGet method to make it 100% reproducible (this should work with any version of Undertow): {code} resp.getOutputStream().close(); try { Thread.sleep(100); } catch (InterruptedException e) { throw new RuntimeException(e); } {code} The underlying problem here is the way the passivation/activation listeners are called. Previously if you did not close the response in the Servlet the session would be closed before the response would be sent, which guaranteed that prePassivate would be called. This also had the side effect that the test would only ever require a single request to see the first session passivating. This is no longer the case, which means the following: - Sometimes session1 has not had its passivation listener called before the session2 request is made - The second session2 request can result in a call to sessionActivated (which makes the test fail). This is especially bogus as there is a chance session2 has not had sessionWillPassivate called yet. The underlying cause of all this is the way listeners are handled in InfinispanSessionManager when persistent is true. Basically: - Requests can cause a session to activate before the passivation listener has been called, resulting in out of order invocations - Multiple concurrent requests to a session will result in multiple activation callbacks, followed by multiple passivation callbacks. Basically at the moment the ordering these events is completely broken. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 January 2016