June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever

by André Félix (JIRA)

[ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.... ] André Félix commented on JGRP-2234: ----------------------------------- Hi [~belaban], I've applied this fix on 3.6.16-SNAPSHOT and tested it. Could you describe what are the next steps to send my code to review? Regards, Felix > Unlocked locks stay locked forever > ---------------------------------- > > Key: JGRP-2234 > URL: https://issues.jboss.org/browse/JGRP-2234 > Project: JGroups > Issue Type: Bug > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 4.0.11 > > Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt > > > As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure. > What we think is happening: > In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever. > Attached is the testng test we wrote and the output of a test failure. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10556) jboss-ejb-client.xml is unable to specify global cluster config

by David Lloyd (JIRA)

David Lloyd created WFLY-10556: ---------------------------------- Summary: jboss-ejb-client.xml is unable to specify global cluster config Key: WFLY-10556 URL: https://issues.jboss.org/browse/WFLY-10556 Project: WildFly Issue Type: Enhancement Components: EJB Affects Versions: 13.0.0.Final Reporter: Brad Maxwell Priority: Critical When configuring an Wildfly instance with EJB Client applications to make remote EJB calls to another Wildfly instance with clustering enabled using a server to server connection configuration, the client Wildfly will specify remote-outbound-connection in the remoting subsystem. The client Wildfly instance will create and maintain these 2 connections in this example below. Client applications deployed on the client Wildfly instance will then package a jboss-ejb-client.xml in the application which specifies the remote server aliases that it wants to have access to. For the application to use clustered ejb, it then specifies the cluster information in the jboss-ejb-client.xml, where it has to specify connection information like username, connection options as opposed to just an alias as in the case of remoting-ejb-receiver. The cluster info should be configured in the JBoss profile xml so that client apps jboss-ejb-client.xml can just reference aliases like the non clustered connections to avoid applications creating their own connections to the same cluster nodes. {code} <subsystem xmlns="urn:jboss:domain:remoting:3.0"> <endpoint/> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> <outbound-connections> <remote-outbound-connection name="remote-ejb-connection-1" outbound-socket-binding-ref="remote-ejb-1" username="ejbuser" security-realm="ApplicationRealm" protocol="http-remoting"> <properties> <property name="SASL_POLICY_NOANONYMOUS" value="false"/> <property name="SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER"/> <property name="SSL_ENABLED" value="false"/> </properties> </remote-outbound-connection> <remote-outbound-connection name="remote-ejb-connection-2" outbound-socket-binding-ref="remote-ejb-2" username="ejbuser" security-realm="ApplicationRealm" protocol="http-remoting"> <properties> <property name="SASL_POLICY_NOANONYMOUS" value="false"/> <property name="SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER"/> <property name="SSL_ENABLED" value="false"/> </properties> </remote-outbound-connection> </outbound-connections> </subsystem> {code} {code} <jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.2" xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd"> <client-context> <ejb-receivers exclude-local-receiver="true"> <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-1" /> <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-2" /> </ejb-receivers> <clusters> <cluster name="ejb" security-realm="ApplicationRealm" username="ejb-cluster-username"> <connection-creation-options> <property name="org.xnio.Options.SSL_ENABLED" value="false" /> <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false" /> </connection-creation-options> </cluster> </clusters> </client-context> </jboss-ejb-client> {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2630) Guided Decision Tables: Not possible to use comma in 'is contained in' when using BRL

by Toni Rikkola (JIRA)

Toni Rikkola created DROOLS-2630: ------------------------------------ Summary: Guided Decision Tables: Not possible to use comma in 'is contained in' when using BRL Key: DROOLS-2630 URL: https://issues.jboss.org/browse/DROOLS-2630 Project: Drools Issue Type: Bug Components: Guided Decision Table Editor Reporter: Toni Rikkola Assignee: Michael Anstis -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-293) Some blades do not boot up correclty without acpi=off

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-293?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-293: ------------------------------------- Already checked: * it's not caused by firmware version (compared b09 and b10) * it's not caused by BIOS version or settings (compared b09 and b10) * not caused by kernel version (b09 and b10 running 3.10.0-862.3.2.el7.x86_64) * not caused by disk partitioning (b04 and b01 have the same) > Some blades do not boot up correclty without acpi=off > ----------------------------------------------------- > > Key: SWSQE-293 > URL: https://issues.jboss.org/browse/SWSQE-293 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Attachments: err.png > > > Following blades do not boot up correctly without acpi=off: > * b04 > * b07 > * b09 > This was already reported to eng-ops [1] for b09 but now the issue is visible again. > [1] - https://redhat.service-now.com/pnt?id=ticket&table=x_redha_pnt_devops_tab... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-293) Some blades do not boot up correclty without acpi=off

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-293?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-293: -------------------------------- Attachment: err.png > Some blades do not boot up correclty without acpi=off > ----------------------------------------------------- > > Key: SWSQE-293 > URL: https://issues.jboss.org/browse/SWSQE-293 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Attachments: err.png > > > Following blades do not boot up correctly without acpi=off: > * b04 > * b07 > * b09 > This was already reported to eng-ops [1] for b09 but now the issue is visible again. > [1] - https://redhat.service-now.com/pnt?id=ticket&table=x_redha_pnt_devops_tab... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10555) The list-messages and remove-messages don't work on a queue when consumer is connected

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-10555?page=com.atlassian.jira.plugin... ] Jeff Mesnil commented on WFLY-10555: ------------------------------------ Have you attached the right zip? The source code looks like the helloworld-jms quickstart (and not able to be either a producer or a consumer) > The list-messages and remove-messages don't work on a queue when consumer is connected > --------------------------------------------------------------------------------------- > > Key: WFLY-10555 > URL: https://issues.jboss.org/browse/WFLY-10555 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 11.0.0.Final, 13.0.0.Final > Reporter: Josef Cacek > Assignee: Jeff Mesnil > Attachments: helloworld-jms.zip > > > The queue operations {{:list-messages}} and {{:remove-messages}} don't work (return empty set) if a consumer is attached to the server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10540) jboss-ejb-client.xml is unable to specify global cluster config

by Dimitris Andreadis (JIRA)

[ https://issues.jboss.org/browse/WFLY-10540?page=com.atlassian.jira.plugin... ] Dimitris Andreadis commented on WFLY-10540: ------------------------------------------- Can [~pferraro], [~flavia.rainone], or someone else take a look at it? We may need this for WF14/EAP 7.2 > jboss-ejb-client.xml is unable to specify global cluster config > --------------------------------------------------------------- > > Key: WFLY-10540 > URL: https://issues.jboss.org/browse/WFLY-10540 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 13.0.0.Final > Reporter: Brad Maxwell > > When configuring an Wildfly instance with EJB Client applications to make remote EJB calls to another Wildfly instance with clustering enabled using a server to server connection configuration, the client Wildfly will specify remote-outbound-connection in the remoting subsystem. The client Wildfly instance will create and maintain these 2 connections in this example below. > Client applications deployed on the client Wildfly instance will then package a jboss-ejb-client.xml in the application which specifies the remote server aliases that it wants to have access to. > For the application to use clustered ejb, it then specifies the cluster information in the jboss-ejb-client.xml, where it has to specify connection information like username, connection options as opposed to just an alias as in the case of remoting-ejb-receiver. > The cluster info should be configured in the JBoss profile xml so that client apps jboss-ejb-client.xml can just reference aliases like the non clustered connections to avoid applications creating their own connections to the same cluster nodes. > {code} > <subsystem xmlns="urn:jboss:domain:remoting:3.0"> > <endpoint/> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > <outbound-connections> > <remote-outbound-connection name="remote-ejb-connection-1" outbound-socket-binding-ref="remote-ejb-1" username="ejbuser" security-realm="ApplicationRealm" protocol="http-remoting"> > <properties> > <property name="SASL_POLICY_NOANONYMOUS" value="false"/> > <property name="SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER"/> > <property name="SSL_ENABLED" value="false"/> > </properties> > </remote-outbound-connection> > <remote-outbound-connection name="remote-ejb-connection-2" outbound-socket-binding-ref="remote-ejb-2" username="ejbuser" security-realm="ApplicationRealm" protocol="http-remoting"> > <properties> > <property name="SASL_POLICY_NOANONYMOUS" value="false"/> > <property name="SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER"/> > <property name="SSL_ENABLED" value="false"/> > </properties> > </remote-outbound-connection> > </outbound-connections> > </subsystem> > {code} > {code} > <jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.2" > xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd"> > <client-context> > <ejb-receivers exclude-local-receiver="true"> > <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-1" /> > <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-2" /> > </ejb-receivers> > <clusters> > <cluster name="ejb" security-realm="ApplicationRealm" > username="ejb-cluster-username"> > <connection-creation-options> > <property name="org.xnio.Options.SSL_ENABLED" value="false" /> > <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" > value="false" /> > </connection-creation-options> > </cluster> > </clusters> > </client-context> > </jboss-ejb-client> > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10540) jboss-ejb-client.xml is unable to specify global cluster config

by Dimitris Andreadis (JIRA)

[ https://issues.jboss.org/browse/WFLY-10540?page=com.atlassian.jira.plugin... ] Dimitris Andreadis updated WFLY-10540: -------------------------------------- Priority: Critical (was: Major) > jboss-ejb-client.xml is unable to specify global cluster config > --------------------------------------------------------------- > > Key: WFLY-10540 > URL: https://issues.jboss.org/browse/WFLY-10540 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 13.0.0.Final > Reporter: Brad Maxwell > Priority: Critical > > When configuring an Wildfly instance with EJB Client applications to make remote EJB calls to another Wildfly instance with clustering enabled using a server to server connection configuration, the client Wildfly will specify remote-outbound-connection in the remoting subsystem. The client Wildfly instance will create and maintain these 2 connections in this example below. > Client applications deployed on the client Wildfly instance will then package a jboss-ejb-client.xml in the application which specifies the remote server aliases that it wants to have access to. > For the application to use clustered ejb, it then specifies the cluster information in the jboss-ejb-client.xml, where it has to specify connection information like username, connection options as opposed to just an alias as in the case of remoting-ejb-receiver. > The cluster info should be configured in the JBoss profile xml so that client apps jboss-ejb-client.xml can just reference aliases like the non clustered connections to avoid applications creating their own connections to the same cluster nodes. > {code} > <subsystem xmlns="urn:jboss:domain:remoting:3.0"> > <endpoint/> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > <outbound-connections> > <remote-outbound-connection name="remote-ejb-connection-1" outbound-socket-binding-ref="remote-ejb-1" username="ejbuser" security-realm="ApplicationRealm" protocol="http-remoting"> > <properties> > <property name="SASL_POLICY_NOANONYMOUS" value="false"/> > <property name="SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER"/> > <property name="SSL_ENABLED" value="false"/> > </properties> > </remote-outbound-connection> > <remote-outbound-connection name="remote-ejb-connection-2" outbound-socket-binding-ref="remote-ejb-2" username="ejbuser" security-realm="ApplicationRealm" protocol="http-remoting"> > <properties> > <property name="SASL_POLICY_NOANONYMOUS" value="false"/> > <property name="SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER"/> > <property name="SSL_ENABLED" value="false"/> > </properties> > </remote-outbound-connection> > </outbound-connections> > </subsystem> > {code} > {code} > <jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.2" > xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd"> > <client-context> > <ejb-receivers exclude-local-receiver="true"> > <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-1" /> > <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-2" /> > </ejb-receivers> > <clusters> > <cluster name="ejb" security-realm="ApplicationRealm" > username="ejb-cluster-username"> > <connection-creation-options> > <property name="org.xnio.Options.SSL_ENABLED" value="false" /> > <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" > value="false" /> > </connection-creation-options> > </cluster> > </clusters> > </client-context> > </jboss-ejb-client> > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-293) Some blades do not boot up correclty without acpi=off

by Filip Brychta (JIRA)

Filip Brychta created SWSQE-293: ----------------------------------- Summary: Some blades do not boot up correclty without acpi=off Key: SWSQE-293 URL: https://issues.jboss.org/browse/SWSQE-293 Project: Kiali QE Issue Type: Task Reporter: Filip Brychta Assignee: Filip Brychta Following blades do not boot up correctly without acpi=off: * b04 * b07 * b09 This was already reported to eng-ops [1] for b09 but now the issue is visible again. [1] - https://redhat.service-now.com/pnt?id=ticket&table=x_redha_pnt_devops_tab... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10543) Do not disable Hibernate enhancements when Hibernate OGM is detected

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10543?page=com.atlassian.jira.plugin... ] Scott Marlow closed WFLY-10543. ------------------------------- > Do not disable Hibernate enhancements when Hibernate OGM is detected > -------------------------------------------------------------------- > > Key: WFLY-10543 > URL: https://issues.jboss.org/browse/WFLY-10543 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 14.0.0.CR1 > > > The JPA Configuration subsystem seems to consider Hibernate OGM as a "non Hibernate" implementation, and so doing disabling a set of nice optimisations all OGM users should be able to benefit from. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

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 June 2018