[JBoss JIRA] (WFLY-6288) java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6288?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-3596 to WFLY-6288:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6288 (was: JBEAP-3596)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
(was: ActiveMQ)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER6)
Affects Testing: (was: Regression)
> java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable
> ----------------------------------------------------------------------
>
> Key: WFLY-6288
> URL: https://issues.jboss.org/browse/WFLY-6288
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Andy Taylor
> Priority: Critical
>
> There is regression against ER5 in failover tests during failback.
> During failback backup server logs lots of errors like:
> {code}
> 17:57:37,163 ERROR [org.xnio.listener] (default I/O-7) XNIO001007: A channel event listener threw an exception: java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.transfer(NettyAcceptor.java:426)
> at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:159)
> at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:147)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:362)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:228)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1226)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1503)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:99)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:178)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:122)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:145)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:121) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> {code}
> This issue might be related to fix for JBEAP-1527.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6288) java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6288?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFLY-6288:
---------------------------------
Assignee: Jeff Mesnil (was: Andy Taylor)
> java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable
> ----------------------------------------------------------------------
>
> Key: WFLY-6288
> URL: https://issues.jboss.org/browse/WFLY-6288
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> There is regression against ER5 in failover tests during failback.
> During failback backup server logs lots of errors like:
> {code}
> 17:57:37,163 ERROR [org.xnio.listener] (default I/O-7) XNIO001007: A channel event listener threw an exception: java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.transfer(NettyAcceptor.java:426)
> at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:159)
> at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:147)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:362)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:228)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1226)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1503)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:99)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:178)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:122)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:145)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:121) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1]
> {code}
> This issue might be related to fix for JBEAP-1527.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (LOGMGR-124) Add marker support
by Robert Knotek (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ]
Robert Knotek commented on LOGMGR-124:
--------------------------------------
But JBoss Logging is not only JUL. JBoss Logging also supports for example SLF4J. And SLF4J API already supports Markers. What I am saying is that JBoss implementation of SLF4J API extends MarkerIgnoringBase. MarkerIgnoringBase is abstract class that simply throws Marker info from all calls.
You are right in fact that JUL does not have Markers in API. But you don't use pure JUL. You extends JUL in ExtLogRecord, so what can be done is to add Marker into ExtLogRecord and propagate it there from APIs which already supports Markers (SLF4J). From APIs without Marker support just null can be propagated.
> Add marker support
> ------------------
>
> Key: LOGMGR-124
> URL: https://issues.jboss.org/browse/LOGMGR-124
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.2.Final
> Reporter: Rob Heine
> Priority: Optional
>
> The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6210) Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols)
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-6210?page=com.atlassian.jira.plugin.... ]
Ladislav Thon updated WFLY-6210:
--------------------------------
Comment: was deleted
(was: A comment with security level 'Red Hat Employee' was removed.)
> Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols)
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6210
> URL: https://issues.jboss.org/browse/WFLY-6210
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 10.1.0.Final
>
>
> {noformat}
> [rhusar@syrah wildfly-10.1.0.Final-SNAPSHOT]$ diff -s standalone/configuration/standalone_xml_history/standalone-ha.initial.xml docs/examples/configs/standalone-ec2-ha.xml
> Files standalone/configuration/standalone_xml_history/standalone-ha.initial.xml and docs/examples/configs/standalone-ec2-ha.xml are identical
> {noformat}
> {noformat}
> [rhusar@syrah wildfly-10.1.0.Final-SNAPSHOT]$ diff -s standalone/configuration/standalone_xml_history/standalone-ha.initial.xml docs/examples/configs/standalone-gossip-ha.xml
> Files standalone/configuration/standalone_xml_history/standalone-ha.initial.xml and docs/examples/configs/standalone-gossip-ha.xml are identical
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6287) CXFHandlerResolverImpl not threadsafe
by Bjørn Hilstad (JIRA)
Bjørn Hilstad created WFLY-6287:
-----------------------------------
Summary: CXFHandlerResolverImpl not threadsafe
Key: WFLY-6287
URL: https://issues.jboss.org/browse/WFLY-6287
Project: WildFly
Issue Type: Bug
Components: Web Services
Affects Versions: 9.0.1.Final
Reporter: Bjørn Hilstad
Assignee: Alessio Soldano
When the concurrency of handler-chain parsing increases , the following error shows up in the logs:
Caused by: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:260)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
at org.jboss.wsf.stack.cxf.client.serviceref.CXFHandlerResolverImpl.createHandlerChain(CXFHandlerResolverImpl.java:161)
... 132 more
One case where I have seen this is when an EJB/MDB uses @WebServiceRef and @HandlerChain to get a reference to a webservice.
When multiple instances of the EJB/MDB are created at the same time to handle a lot of messages this happens.
It is the @HandlerChain that triggers the xml parsing and gives the error.
The Xerces DocumentBuilder is not threadsafe and thus requires code to synchronize it correctly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1399) Failure when resolving an expression with the default value containing a '$' at the end
by Valentin Maechler (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1399?page=com.atlassian.jira.plugi... ]
Valentin Maechler commented on WFCORE-1399:
-------------------------------------------
Hello,
Is there any change this gets soon integrated into a bugfix release?
The state of the pull request seems to be somehow blocked.
Thanks for an explanation.
Regards,
Valentin
(Restricted to jira-users group)
> Failure when resolving an expression with the default value containing a '$' at the end
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1399
> URL: https://issues.jboss.org/browse/WFCORE-1399
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.CR1
> Reporter: Valentin Maechler
> Assignee: ehsavoie Hugonnet
> Attachments: ExpressionResolver.java, ExpressionResolverUnitTestCase.java
>
>
> Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value.
> e.g. {code}
> value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}"
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months