March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout

by Tomohisa igarashi (JIRA)

[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ] Tomohisa igarashi commented on WFLY-6420: ----------------------------------------- No, using BOM doesn't solve the issue, just using JMS 2.0 way of client code (JMSContext) could get around the issue like I said in my previous comment. [~jmesnil] do you mean WildFly10 doesn't support JMS 1.1 client code (Connection/Session)? > 30secs delay on consumer.receive() in spite of shorter timeout > -------------------------------------------------------------- > > Key: WFLY-6420 > URL: https://issues.jboss.org/browse/WFLY-6420 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Tomohisa igarashi > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz > > > consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases. > The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFLY-4866. ------------------------------- Fix Version/s: 10.0.0.CR5 (was: 10.0.0.CR3) Resolution: Done Artemis underlying issue was fixed in Artemis 1.1.0.wildfly-009 > messaging-activemq: NPE when http-acceptor and https-acceptor configured > ------------------------------------------------------------------------ > > Key: WFLY-4866 > URL: https://issues.jboss.org/browse/WFLY-4866 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final, 10.0.0.CR2 > Environment: Windows 7 Pro, Java 7u55 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Labels: JMS, Messaging > Fix For: 10.0.0.CR5 > > Attachments: server-logs.zip > > > 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.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-102) Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-102: ------------------------------------------------ Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1299102|https://bugzilla.redhat.com/show_bug.cgi?id=1299102] from NEW to ASSIGNED > Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback > -------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-102 > URL: https://issues.jboss.org/browse/WFCORE-102 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha9 > > > The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so. > To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6420) 30secs delay on consumer.receive() in spite of shorter timeout

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6420?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFLY-6420. ------------------------------- Resolution: Rejected Using wildfly jms client BOM to use the correct dependencies solve the issue. > 30secs delay on consumer.receive() in spite of shorter timeout > -------------------------------------------------------------- > > Key: WFLY-6420 > URL: https://issues.jboss.org/browse/WFLY-6420 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Tomohisa igarashi > Assignee: Jeff Mesnil > Fix For: 10.1.0.Final > > Attachments: artemis-hornetq-client.tgz, artemis-hornetq-client.tgz > > > consumer.receive() is blocked 30secs even if shorter timeout is specified. Attached a maven project including testcases. > The ArtemisStandaloneTest do same against embedded server, but this in contrast works fine. So the issue seems to happen only on WildFly via http upgrade connection. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5796) Topic Subscriber does only get messages produced on node 2 after failover and failback of node 1

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5796?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-5796: ------------------------------ Summary: Topic Subscriber does only get messages produced on node 2 after failover and failback of node 1 (was: Topic Subsriber does only get messages produced on node 2 after failover and failback of node 1) > Topic Subscriber does only get messages produced on node 2 after failover and failback of node 1 > ------------------------------------------------------------------------------------------------ > > Key: WFLY-5796 > URL: https://issues.jboss.org/browse/WFLY-5796 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR4 > Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment. > Reporter: Michal Sudra > Assignee: Jeff Mesnil > Attachments: domain.xml, host.xml > > > Client (Topic Subscriber) is connected to a 2 node symmetrical colocated life backup cluster receiving messages produced on any node (random). > Observed behavior: > When node 1 is shut down (failover to node 2). -> Client is automatically failing over to node 2 and is continuing to consume messages produced on node 2. > Then node 1 is restarted (failback to node 1). From now on the client is only receiving messages produced on node 2, not messages produced on node 1. > When node 2 is shut down (failover to node 1). -> Client is automatically failing over to node 1 and is continuing to consume messages produced on node 1. > Then node 2 is restarted (failback to node 2). From now on the client is only receiving messages produced on node 1, not messages produced on node 2. > Expected behavior: > The client should at any time receive all messages regardless on which node the message is produced. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5796) Topic Subsriber does only get messages produced on node 2 after failover and failback of node 1

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5796?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-5796: ----------------------------------- I wonder if this issue is caused by https://issues.apache.org/jira/browse/ARTEMIS-425 (like WFLY-5795). Does the issue also occur if the notification address is commented out in the messaging-activemq subsystem configuration in domain.xml? > Topic Subsriber does only get messages produced on node 2 after failover and failback of node 1 > ----------------------------------------------------------------------------------------------- > > Key: WFLY-5796 > URL: https://issues.jboss.org/browse/WFLY-5796 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR4 > Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment. > Reporter: Michal Sudra > Assignee: Jeff Mesnil > Attachments: domain.xml, host.xml > > > Client (Topic Subscriber) is connected to a 2 node symmetrical colocated life backup cluster receiving messages produced on any node (random). > Observed behavior: > When node 1 is shut down (failover to node 2). -> Client is automatically failing over to node 2 and is continuing to consume messages produced on node 2. > Then node 1 is restarted (failback to node 1). From now on the client is only receiving messages produced on node 2, not messages produced on node 1. > When node 2 is shut down (failover to node 1). -> Client is automatically failing over to node 1 and is continuing to consume messages produced on node 1. > Then node 2 is restarted (failback to node 2). From now on the client is only receiving messages produced on node 1, not messages produced on node 2. > Expected behavior: > The client should at any time receive all messages regardless on which node the message is produced. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1109) Change Impact: modify drools-compiler so that information is collected during compilation

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1109?page=com.atlassian.jira.plugi... ] Marco Rietveld updated DROOLS-1109: ----------------------------------- Description: The problem is that Action instances created at compile time by {{drools-compiler}} contain reference information that can otherwise not be retrieved by parsing the DRL. The code associated with this issue adds an (compiler) option to retrieve this information during compilation, so that (indexer) code in the workbench can take advantage of this code so subsequently index and use when analysing change impact and doing refactoring operations. > Change Impact: modify drools-compiler so that information is collected during compilation > ----------------------------------------------------------------------------------------- > > Key: DROOLS-1109 > URL: https://issues.jboss.org/browse/DROOLS-1109 > Project: Drools > Issue Type: Task > Affects Versions: 6.3.0.Final > Reporter: Marco Rietveld > Assignee: Marco Rietveld > > The problem is that Action instances created at compile time by {{drools-compiler}} contain reference information that can otherwise not be retrieved by parsing the DRL. > The code associated with this issue adds an (compiler) option to retrieve this information during compilation, so that (indexer) code in the workbench can take advantage of this code so subsequently index and use when analysing change impact and doing refactoring operations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1061) After failed mvel function call fireAllRules could put drools into infinite loop

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1061?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1061. ------------------------------- Resolution: Won't Fix When a KieSession throws an exception (either during constraint evaluation as in your case or during the firing of a consequence) the session itself has to be considered dead and then no longer usable. In particular it's up to the user to guarantee that all the constraints can be evaluated without throwing any exception. > After failed mvel function call fireAllRules could put drools into infinite loop > -------------------------------------------------------------------------------- > > Key: DROOLS-1061 > URL: https://issues.jboss.org/browse/DROOLS-1061 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final, 6.4.0.Beta1 > Reporter: Tomi Pakarinen > Assignee: Mario Fusco > > Example test case is available here https://gist.github.com/patope/ea9eb97b8d45e75ccf7c -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1109) Change Impace: Modify drools-compiler so that information is collected during compilation

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1109?page=com.atlassian.jira.plugi... ] Marco Rietveld updated DROOLS-1109: ----------------------------------- Summary: Change Impace: Modify drools-compiler so that information is collected during compilation (was: Modify drools-compiler so that information is collected during compilation) > Change Impace: Modify drools-compiler so that information is collected during compilation > ----------------------------------------------------------------------------------------- > > Key: DROOLS-1109 > URL: https://issues.jboss.org/browse/DROOLS-1109 > Project: Drools > Issue Type: Task > Affects Versions: 6.3.0.Final > Reporter: Marco Rietveld > Assignee: Marco Rietveld > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1109) Change Impact: modify drools-compiler so that information is collected during compilation

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1109?page=com.atlassian.jira.plugi... ] Marco Rietveld updated DROOLS-1109: ----------------------------------- Summary: Change Impact: modify drools-compiler so that information is collected during compilation (was: Change Impace: Modify drools-compiler so that information is collected during compilation) > Change Impact: modify drools-compiler so that information is collected during compilation > ----------------------------------------------------------------------------------------- > > Key: DROOLS-1109 > URL: https://issues.jboss.org/browse/DROOLS-1109 > Project: Drools > Issue Type: Task > Affects Versions: 6.3.0.Final > Reporter: Marco Rietveld > Assignee: Marco Rietveld > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 March 2016