September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3225) CLI, keep full stack trace

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3225?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-3225: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2827 > CLI, keep full stack trace > -------------------------- > > Key: WFCORE-3225 > URL: https://issues.jboss.org/browse/WFCORE-3225 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Minor > > CLI is re-throwing the exception thrown in the async task. The calling stack is lost. It has no impact for CLI users but is annoying when using CLI programmatically. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1735) Fetch KieSession from Kbase using session name

by Chandresh Mishra (JIRA)

Chandresh Mishra created DROOLS-1735: ---------------------------------------- Summary: Fetch KieSession from Kbase using session name Key: DROOLS-1735 URL: https://issues.jboss.org/browse/DROOLS-1735 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.3.0.Final Reporter: Chandresh Mishra Assignee: Mario Fusco KieSession kSession = kContainer.getKieBase("KiebaseName")).newKieSession(); There is no method available in KieBase to get KieSession by passing the session name. which is similar to get session from container kSession = kContainer.newKieSession("SessionName"); So , We can not choose a particular kieBase and KieSession at a same time by passing the name for both. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3302) Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3302: ---------------------------------------- Summary: Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5 Key: WFCORE-3302 URL: https://issues.jboss.org/browse/WFCORE-3302 Project: WildFly Core Issue Type: Bug Components: Domain Management, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet: {code} java.lang.RuntimeException: java.net.BindException: Address already in use: bind at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:433) at sun.nio.ch.Net.bind(Net.java:425) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67) at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181) at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282) at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372) at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92) at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88) at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94) at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346) {code} These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests. I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method. The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens: {code} "XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable java.lang.Thread.State: RUNNABLE at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307) - locked <0xc0d> (a java.lang.Object) at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229) at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149) - locked <0xc38> (a java.util.HashSet) at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) - locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl) - locked <0xc39> (a java.util.Collections$UnmodifiableSet) - locked <0xc3a> (a sun.nio.ch.Util$2) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at org.xnio.nio.WorkerThread.run(WorkerThread.java:519) {code} That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket. I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed. I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9354) Typo in error message WFLYAC0023

by Wolfgang Knauf (JIRA)

Wolfgang Knauf created WFLY-9354: ------------------------------------ Summary: Typo in error message WFLYAC0023 Key: WFLY-9354 URL: https://issues.jboss.org/browse/WFLY-9354 Project: WildFly Issue Type: Bug Components: Application Client Affects Versions: 11.0.0.CR1 Reporter: Wolfgang Knauf Assignee: Stuart Douglas Priority: Trivial When starting a JavaEE application client with invalid ear/jar name, the error message lacks a "not" ("could NOT find application client..."): C:\Temp>c:\Temp\wildfly-11.0.0.CR1\bin\appclient.bat some.ear#some.jar Calling "c:\Temp\wildfly-11.0.0.CR1\bin\appclient.conf.bat" JAVA_HOME is not set. Unexpected results may occur. Set JAVA_HOME to the directory of your local JDK to avoid this message. 12:35:47,789 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Final java.lang.RuntimeException: *WFLYAC0023: Could find application client* C:\Temp\so me.ear at org.jboss.as.appclient.subsystem.Main.main(Main.java:133) at org.jboss.modules.Module.run(Module.java:344) at org.jboss.modules.Main.main(Main.java:525) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9353) system property to set cluster name

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9353?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9353: ------------------------------ Component/s: Clustering (was: Server) > system property to set cluster name > ----------------------------------- > > Key: WFLY-9353 > URL: https://issues.jboss.org/browse/WFLY-9353 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Jason Greene > > The cluster name is basically always server/web/ejb/hibernate/... as shown below. It would be useful to define a system property substitution in the standard configs to make it easy to set for instances where multiple clusters are needed. > Something like ${jboss.cluster.name:}-ejb or ${jboss.partition.name:DefaultPartition} would make it clear what the cluster name is and how to change it. > {code} > <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> > <transport lock-timeout="60000" cluster="${jboss.cluster.name:}-ejb"/> > {code} > {code} > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server"> > <transport lock-timeout="60000"/> > ... > <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan"> > <transport lock-timeout="60000"/> > ... > <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> > <transport lock-timeout="60000"/> > ... > <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> > <transport lock-timeout="60000"/> > ... > </subsystem> > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9353) system property to set cluster name

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9353?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-9353: --------------------------------- Assignee: Paul Ferraro (was: Jason Greene) > system property to set cluster name > ----------------------------------- > > Key: WFLY-9353 > URL: https://issues.jboss.org/browse/WFLY-9353 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Paul Ferraro > > The cluster name is basically always server/web/ejb/hibernate/... as shown below. It would be useful to define a system property substitution in the standard configs to make it easy to set for instances where multiple clusters are needed. > Something like ${jboss.cluster.name:}-ejb or ${jboss.partition.name:DefaultPartition} would make it clear what the cluster name is and how to change it. > {code} > <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> > <transport lock-timeout="60000" cluster="${jboss.cluster.name:}-ejb"/> > {code} > {code} > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server"> > <transport lock-timeout="60000"/> > ... > <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan"> > <transport lock-timeout="60000"/> > ... > <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> > <transport lock-timeout="60000"/> > ... > <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> > <transport lock-timeout="60000"/> > ... > </subsystem> > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9353) system property to set cluster name

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-9353: ---------------------------------- Summary: system property to set cluster name Key: WFLY-9353 URL: https://issues.jboss.org/browse/WFLY-9353 Project: WildFly Issue Type: Enhancement Components: Server Affects Versions: 11.0.0.CR1 Reporter: Brad Maxwell Assignee: Jason Greene The cluster name is basically always server/web/ejb/hibernate/... as shown below. It would be useful to define a system property substitution in the standard configs to make it easy to set for instances where multiple clusters are needed. Something like ${jboss.cluster.name:}-ejb or ${jboss.partition.name:DefaultPartition} would make it clear what the cluster name is and how to change it. {code} <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> <transport lock-timeout="60000" cluster="${jboss.cluster.name:}-ejb"/> {code} {code} <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server"> <transport lock-timeout="60000"/> ... <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan"> <transport lock-timeout="60000"/> ... <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> <transport lock-timeout="60000"/> ... <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> <transport lock-timeout="60000"/> ... </subsystem> {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9352) Upgrade WildFly HTTP client components to 1.0.3.Final

by David Lloyd (JIRA)

David Lloyd created WFLY-9352: --------------------------------- Summary: Upgrade WildFly HTTP client components to 1.0.3.Final Key: WFLY-9352 URL: https://issues.jboss.org/browse/WFLY-9352 Project: WildFly Issue Type: Component Upgrade Components: EJB, Naming, Transactions Reporter: David Lloyd Assignee: David Lloyd Priority: Blocker Fix For: 11.0.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9351) Upgrade JBoss EJB Client to 4.0.1.Final

by David Lloyd (JIRA)

David Lloyd created WFLY-9351: --------------------------------- Summary: Upgrade JBoss EJB Client to 4.0.1.Final Key: WFLY-9351 URL: https://issues.jboss.org/browse/WFLY-9351 Project: WildFly Issue Type: Component Upgrade Components: EJB Reporter: David Lloyd Assignee: David Lloyd Priority: Blocker Fix For: 11.0.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9350) Upgrade WildFly Transaction Client to 1.0.1.Final

by David Lloyd (JIRA)

David Lloyd created WFLY-9350: --------------------------------- Summary: Upgrade WildFly Transaction Client to 1.0.1.Final Key: WFLY-9350 URL: https://issues.jboss.org/browse/WFLY-9350 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: David Lloyd Assignee: David Lloyd Priority: Blocker Fix For: 11.0.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 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 September 2017