June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4255) Allow Arquillian to specify a timeout value for the WildFly clean shutdown mechanism when shutting down a server

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4255?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-4255: --------------------------------- Fix Version/s: 11.0.0.Alpha1 > Allow Arquillian to specify a timeout value for the WildFly clean shutdown mechanism when shutting down a server > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4255 > URL: https://issues.jboss.org/browse/WFLY-4255 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Radoslav Husar > Fix For: 11.0.0.Alpha1 > > > WildFly has a clean shutdown mechanism which can be used to shutdown a server from the command line so that requests active at the time of shutdown get a chance to complete: > {code} > [standalone@localhost:9990 /] :shutdown(timeout=5) > {"outcome" => "success"} > {code} > Provide access to this feature from an Arquillian test case so that test cases may test with or without clean shutdown enabled. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still fails intermittently

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-3532: --------------------------------- Fix Version/s: 11.0.0.Alpha1 (was: 10.1.0.Final) > RemoteFailoverTestCase still fails intermittently > -------------------------------------------------- > > Key: WFLY-3532 > URL: https://issues.jboss.org/browse/WFLY-3532 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: clean_undeploy > Fix For: 11.0.0.Alpha1 > > > Fail rate is at 1.5% atm. > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI... > (making affected version alpha, but indeed its master) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2645) SFSB containing injected DataSource fails to passivate/serialize

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2645?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-2645: --------------------------------- Fix Version/s: 9.0.0.Beta1 > SFSB containing injected DataSource fails to passivate/serialize > ---------------------------------------------------------------- > > Key: WFLY-2645 > URL: https://issues.jboss.org/browse/WFLY-2645 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Stefano Maestri > Priority: Critical > Fix For: 9.0.0.Beta1 > > > See JBPAPP6-1762 for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6792) Batch deployment resources should get the service registry without modification flags for read-only ops

by James Perkins (JIRA)

James Perkins created WFLY-6792: ----------------------------------- Summary: Batch deployment resources should get the service registry without modification flags for read-only ops Key: WFLY-6792 URL: https://issues.jboss.org/browse/WFLY-6792 Project: WildFly Issue Type: Bug Components: Batch Reporter: James Perkins Assignee: Cheng Fang All batch deployment operations get the service registry as a modifiable registry which uses locks that are not required for read-only ops. Operations like {{start}}, {{stop}} and {{restart}} will need to continue using a modifiable service registry, but read ops should not acquire a modifiable service registry. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected

by Preeta Kuruvilla (JIRA)

[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ] Preeta Kuruvilla commented on WFLY-6781: ---------------------------------------- Inline please find my comments. I'm confused, as you seem to be using the terms RC and SL to interchangeably refer to web applications (e.g. RC.war and SL.rar) and a mysterious component with a remoting connection (e.g. RC communicates remotely with SL). What kind of component is this? How is the remoting connection used? {color:#205081}Preeta: RC.war and SL.war are 2 applications we deploy on Wildfly. Both of them work together in our product. RC is clustered and hence it is deployed on Node1 and Node2 while SL(non-clustered) exist only on Node1. RC on Node1 and Node2 communicates with SL on Node1 through JMS which is configured on SL. The JMS Jndi URL to connect is http-remoting://ip-address:6080.{color} server-host1-RC and server-host1-SL belong to different server groups - but I don't know how these server groups are configured. You seem to be managing the server instance of each node as its own domain, is that right? Why is that? How do the configurations of these domains differ? {color:#205081}Preeta: As I said, RC is clustered while SL is non-clustered and both are different components, hence they belong to different server groups although managed by one domain. The Domain controller is just one and it is in Node1. {color} "By the way RC communicates remotely with JMS on SL using the below url : http-remoting://<ip address of SL which is Node1>:6080/" What is the context in which this url is used? Is this a JNDI provider URL? Details please. {color:#205081}Preeta: Yes, it is JMS JNDI provider URL. As I said above, the JMS is configured on SL and RC connects to JMS using this url.{color} Remoting connections are point-to-point connections and don't magically failover if the target location becomes unavailable. What exactly is your expectation here? {color:#205081}Preeta: When network on Node2 is disabled, then Node1 should gracefully take over and RC in Node1 should continue to connect to JMS/SL on Node1. But what is happening is that the SL(on Node1) is not processing the request that comes from RC in Node1 {color} I still don't understand exactly what aspect of your system is "clustered". I also don't understand which connections you expect to failover. Which (and what kind of) components are clustered? Do your logs indicate proper cluster formation? What do your logs indicate when you test these failure scenarios? {color:#205081}Preeta: Only RC is clustered and not the SL. I have answered this above. Yes our logs indicate proper cluster formation. On disabling network on Node2, the service on Node2 does not come out of execution. It throws error saying "connection got disconnected", which is correct. The issue is that the Node1 under this condition does not work as expected, meaning the SL is not processing the request that comes from RC in Node1. {color} {color:#205081}Note: Things work as expected when we give Ctrl +C on Node2 or else when we stop the server on Node2 from the admin console.{color} > Wildfly cluster's failover functionality doesn't work as expected > ----------------------------------------------------------------- > > Key: WFLY-6781 > URL: https://issues.jboss.org/browse/WFLY-6781 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > Priority: Blocker > > Following are the testing scenarios we did and the outcome:- > 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment. > 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment. > 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment > 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment. > Jgroups subsystem configuration in domain.xml we have is below:- > <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp"> > <stack name="udp"> > <transport type="UDP" socket-binding="jgroups-udp"/> > <protocol type="PING"/> > <protocol type="MERGE3"/> > <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/> > <protocol type="FD_ALL"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="UFC"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > <stack name="tcp"> > <transport type="TCP" socket-binding="jgroups-tcp"/> > <protocol type="MPING" socket-binding="jgroups-mping"/> > <protocol type="MERGE2"/> > <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/> > <protocol type="FD"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > </subsystem> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6682) Upgrade Hibernate to 5.2.0

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6682?page=com.atlassian.jira.plugin.... ] Scott Marlow edited comment on WFLY-6682 at 6/29/16 10:48 AM: -------------------------------------------------------------- At *least* I'm down from 5 accounts to 3 :-) I just put in a request to remove the two extra accounts, thanks for the reminder! was (Author: smarlow): At I'm down from 5 accounts to 3 :-) I just put in a request to remove the two extra accounts, thanks for the reminder! > Upgrade Hibernate to 5.2.0 > -------------------------- > > Key: WFLY-6682 > URL: https://issues.jboss.org/browse/WFLY-6682 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Frank Langelage > Assignee: Scott Marlow > Priority: Optional > Fix For: 10.1.0.Final > > Attachments: screenshot-1.png > > > Upgrade Hibernate to latest version 5.2.0.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6682) Upgrade Hibernate to 5.2.0

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6682?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-6682: ------------------------------------ At I'm down from 5 accounts to 3 :-) I just put in a request to remove the two extra accounts, thanks for the reminder! > Upgrade Hibernate to 5.2.0 > -------------------------- > > Key: WFLY-6682 > URL: https://issues.jboss.org/browse/WFLY-6682 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Frank Langelage > Assignee: Scott Marlow > Priority: Optional > Fix For: 10.1.0.Final > > Attachments: screenshot-1.png > > > Upgrade Hibernate to latest version 5.2.0.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6791) Upgrade to Hibernate Search 5.5.4.Final

by Sanne Grinovero (JIRA)

Sanne Grinovero created WFLY-6791: ------------------------------------- Summary: Upgrade to Hibernate Search 5.5.4.Final Key: WFLY-6791 URL: https://issues.jboss.org/browse/WFLY-6791 Project: WildFly Issue Type: Component Upgrade Components: JPA / Hibernate Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 10.1.0.Final We released a new micro version of Hibernate Search. Fully backwards compatible, yet has some nice performance improvements and a bugfix. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6270) Update to lucene-5.4 to align with camel-2.17

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/WFLY-6270?page=com.atlassian.jira.plugin.... ] Sanne Grinovero resolved WFLY-6270. ----------------------------------- Resolution: Rejected > Update to lucene-5.4 to align with camel-2.17 > --------------------------------------------- > > Key: WFLY-6270 > URL: https://issues.jboss.org/browse/WFLY-6270 > Project: WildFly > Issue Type: Feature Request > Reporter: Thomas Diesler > Assignee: Sanne Grinovero > > Camel currently uses lucene-5.4.1 > https://github.com/apache/camel/blob/master/parent/pom.xml#L366 > CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1061 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6781: ------------------------------------ I'm confused, as you seem to be using the terms RC and SL to interchangeably refer to web applications (e.g. RC.war and SL.rar) and a mysterious component with a remoting connection (e.g. RC communicates remotely with SL). What kind of component is this? How is the remoting connection used? server-host1-RC and server-host1-SL belong to different server groups - but I don't know how these server groups are configured. You seem to be managing the server instance of each node as its own domain, is that right? Why is that? How do the configurations of these domains differ? "By the way RC communicates remotely with SL using the below url : http-remoting://<ip address of SL which is Node1>:6080/" What is the context in which this url is used? Is this a JNDI provider URL? Details please. Remoting connections are point-to-point connections and don't magically failover if the target location becomes unavailable. What exactly is your expectation here? I still don't understand exactly what aspect of your system is "clustered". I also don't understand which connections you expect to failover. Which (and what kind of) components are clustered? Do your logs indicate proper cluster formation? What do your logs indicate when you test these failure scenarios? > Wildfly cluster's failover functionality doesn't work as expected > ----------------------------------------------------------------- > > Key: WFLY-6781 > URL: https://issues.jboss.org/browse/WFLY-6781 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > Priority: Blocker > > Following are the testing scenarios we did and the outcome:- > 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment. > 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment. > 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment > 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment. > Jgroups subsystem configuration in domain.xml we have is below:- > <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp"> > <stack name="udp"> > <transport type="UDP" socket-binding="jgroups-udp"/> > <protocol type="PING"/> > <protocol type="MERGE3"/> > <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/> > <protocol type="FD_ALL"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="UFC"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > <stack name="tcp"> > <transport type="TCP" socket-binding="jgroups-tcp"/> > <protocol type="MPING" socket-binding="jgroups-mping"/> > <protocol type="MERGE2"/> > <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/> > <protocol type="FD"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="RSVP"/> > </stack> > </subsystem> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016