March 2016 - jboss-jira - Jboss List Archives

[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)

9 years, 9 months

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)

9 years, 9 months

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)

9 years, 9 months

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)

9 years, 9 months

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)

9 years, 9 months

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)

9 years, 9 months

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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1109) 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 moved GUVNOR-2475 to DROOLS-1109: ------------------------------------------------ Project: Drools (was: Guvnor) Key: DROOLS-1109 (was: GUVNOR-2475) Workflow: GIT Pull Request workflow (was: classic default workflow) Affects Version/s: 6.3.0.Final (was: drools_6.3.0.Final) > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2035) Util class tries to locate resource bundles using TCCL, which fails

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/JGRP-2035?page=com.atlassian.jira.plugin.... ] Jan Martiska updated JGRP-2035: ------------------------------- Steps to Reproduce: In EAP 7.0.0.ER7, deploy an application containing a persistence.xml containing this {noformat} <property name="hibernate.cache.use_second_level_cache" value="true" /> <property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.infinispan.InfinispanRegionFactory" /> {noformat} was: In EAP 7.0.0.ER7, deploy an application containing a persistence.xml containing this {noformat} <property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.infinispan.InfinispanRegionFactory" /> {noformat} > Util class tries to locate resource bundles using TCCL, which fails > ------------------------------------------------------------------- > > Key: JGRP-2035 > URL: https://issues.jboss.org/browse/JGRP-2035 > Project: JGroups > Issue Type: Bug > Reporter: Jan Martiska > Assignee: Bela Ban > Priority: Blocker > > {{org.jgroups.util.Util}} class tries to locate jg-messages bundle using the TCCL, not its own class loader. In a Java SE environment, this typically doesn't matter, because the class loaders are the same, but in EAP, this means that jg-messages is sought by the class loader of the application rather than the class loader of JGroups module, which is obviously wrong. This is the offending line: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... > The call to getBundle fails with a MissingResourceException (see http://docs.oracle.com/javase/6/docs/api/java/util/ResourceBundle.html#ge...) and because this code is in a static initializer, the Util class becomes unusable. > This causes Hibernate applications with 2LC infinispan clustering backend to not work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2036) Util class tries to locate resource bundles using TCCL, which fails

by Jan Martiska (JIRA)

Jan Martiska created JGRP-2036: ---------------------------------- Summary: Util class tries to locate resource bundles using TCCL, which fails Key: JGRP-2036 URL: https://issues.jboss.org/browse/JGRP-2036 Project: JGroups Issue Type: Bug Reporter: Jan Martiska Assignee: Bela Ban Priority: Blocker {{org.jgroups.util.Util}} class tries to locate jg-messages bundle using the TCCL, not its own class loader. In a Java SE environment, this typically doesn't matter, because the class loaders are the same, but in EAP, this means that jg-messages is sought by the class loader of the application rather than the class loader of JGroups module, which is obviously wrong. This is the offending line: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... The call to getBundle fails with a MissingResourceException (see http://docs.oracle.com/javase/6/docs/api/java/util/ResourceBundle.html#ge...) and because this code is in a static initializer, the Util class becomes unusable. This causes Hibernate applications with 2LC infinispan clustering backend to not work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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 March 2016