[JBoss JIRA] (WFLY-4132) Transaction subsystem does not initialise the recovery store correctly
by Michael Musgrove (JIRA)
Michael Musgrove created WFLY-4132:
--------------------------------------
Summary: Transaction subsystem does not initialise the recovery store correctly
Key: WFLY-4132
URL: https://issues.jboss.org/browse/WFLY-4132
Project: WildFly
Issue Type: Bug
Components: Transactions
Affects Versions: 9.0.0.Alpha1
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 9.0.0.Beta1
The initialisation code in the transaction subsystem sets the transaction log directory on the wrong instance (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...). The code should pass in the null string for the instance name to get the default instance.
The bug arises because we recently fixed JBTM-2207 in order to avoid string comparison with the default name and the reason this is not a backwards compatibility issue is that com.arjuna.common.internal.util.propertyservice.BeanPopulator is internal code that the app server is using.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 11 months
[JBoss JIRA] (WFLY-4131) TransportConfiguration does not check the name in equals
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-4131:
---------------------------------
Summary: TransportConfiguration does not check the name in equals
Key: WFLY-4131
URL: https://issues.jboss.org/browse/WFLY-4131
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 8.1.0.Final
Environment: Windows 7 Pro, Java 7u55
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log.
I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped.
Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException.
I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method.
The workaround in the ticket works because the redundant <param> causes the equals() method to see the two acceptors as unequal.
The exception was:
[exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
[exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161)
[exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153)
[exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
[exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
[exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271)
[exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221)
[exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131)
[exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351)
[exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78)
[exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
[exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273)
[exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207)
[exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
[exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
[exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
[exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
[exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
[exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45)
[exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
[exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
[exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
[exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
[exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
[exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
[exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
[exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 11 months