April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2045) Can't init JChannel using FILE_PING when JVM is shutting down

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2045?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2045: --------------------------- Fix Version/s: 4.0 > Can't init JChannel using FILE_PING when JVM is shutting down > ------------------------------------------------------------- > > Key: JGRP-2045 > URL: https://issues.jboss.org/browse/JGRP-2045 > Project: JGroups > Issue Type: Bug > Reporter: Justin Bertram > Assignee: Bela Ban > Fix For: 4.0 > > > The ActiveMQ Artemis message broker, which can use JGroups for clustering, can be configured to forward any pending messages to another broker in the cluster when it is shutdown. However, since the JVM is in the process of shutting down the shutdown hook which org.jgroups.protocols.FILE_PING#init attempts to add fails and the broker is unable to move its messages. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2046) Order of XSD protocol elements and protocol attributes is arbitrary

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2046?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2046: --------------------------- Fix Version/s: 4.0 > Order of XSD protocol elements and protocol attributes is arbitrary > ------------------------------------------------------------------- > > Key: JGRP-2046 > URL: https://issues.jboss.org/browse/JGRP-2046 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.8 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 4.0 > > > While fixing JGRP-2037 I realized that the order in the XSD is completely random/arbitrary/undefined. The order relies on hash-based collections, undefined order from reflection classes, etc. > This makes impossible to compare XSDs from other builds or other versions to see what changed. > Probably the best approach is to sort both collections with classes and collections with attributes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1473) Improve inter-process operation handling for :suspend-servers using a blocking timout

by Yeray Santana Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1473?page=com.atlassian.jira.plugi... ] Yeray Santana Borges updated WFCORE-1473: ----------------------------------------- Description: This issue has been created from [~brian.stansberry]'s comments on [https://github.com/wildfly/wildfly-core/pull/1490]. That pull request is related with WFCORE-1467. :suspend-server operation internally is using two calls without a blocking timeout limit: # A call which waits for the operation to be prepared in the managed server # A call which waits for the complete message sent by the managed server The idea with this issue is to add a blocking timeout limit for those calls, in this case the default blocking timeout defined for each managed server. was: This issue has been created from [~brian.stansberry]'s comments on [https://github.com/wildfly/wildfly-core/pull/1490]. That pull request is related with WFCORE-1467. :suspend-server operation internally is using two calls without a blocking timeout limit: # A call which waits for the operation to be prepared in the managed server # A call which waits for the complete message sent by the managed server The idea with this issue is to add a blocking timeout limit for those calls, in this case the default blocking timeout defined for each managed server in those operations. > Improve inter-process operation handling for :suspend-servers using a blocking timout > ------------------------------------------------------------------------------------- > > Key: WFCORE-1473 > URL: https://issues.jboss.org/browse/WFCORE-1473 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Yeray Santana Borges > Assignee: Yeray Santana Borges > > This issue has been created from [~brian.stansberry]'s comments on [https://github.com/wildfly/wildfly-core/pull/1490]. That pull request is related with WFCORE-1467. > :suspend-server operation internally is using two calls without a blocking timeout limit: > # A call which waits for the operation to be prepared in the managed server > # A call which waits for the complete message sent by the managed server > The idea with this issue is to add a blocking timeout limit for those calls, in this case the default blocking timeout defined for each managed server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1473) Improve inter-process operation handling for :suspend-servers using a blocking timout

by Yeray Santana Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1473?page=com.atlassian.jira.plugi... ] Yeray Santana Borges reassigned WFCORE-1473: -------------------------------------------- Assignee: Yeray Santana Borges (was: Brian Stansberry) > Improve inter-process operation handling for :suspend-servers using a blocking timout > ------------------------------------------------------------------------------------- > > Key: WFCORE-1473 > URL: https://issues.jboss.org/browse/WFCORE-1473 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Yeray Santana Borges > Assignee: Yeray Santana Borges > > This issue has been created from [~brian.stansberry]'s comments on [https://github.com/wildfly/wildfly-core/pull/1490]. That pull request is related with WFCORE-1467. > :suspend-server operation internally is using two calls without a blocking timeout limit: > # A call which waits for the operation to be prepared in the managed server > # A call which waits for the complete message sent by the managed server > The idea with this issue is to add a blocking timeout limit for those calls, in this case the default blocking timeout defined for each managed server in those operations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1473) Improve inter-process operation handling for :suspend-servers using a blocking timout

by Yeray Santana Borges (JIRA)

Yeray Santana Borges created WFCORE-1473: -------------------------------------------- Summary: Improve inter-process operation handling for :suspend-servers using a blocking timout Key: WFCORE-1473 URL: https://issues.jboss.org/browse/WFCORE-1473 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Yeray Santana Borges Assignee: Brian Stansberry This issue has been created from [~brian.stansberry]'s comments on [https://github.com/wildfly/wildfly-core/pull/1490]. That pull request is related with WFCORE-1467. :suspend-server operation internally is using two calls without a blocking timeout limit: # A call which waits for the operation to be prepared in the managed server # A call which waits for the complete message sent by the managed server The idea with this issue is to add a blocking timeout limit for those calls, in this case the default blocking timeout defined for each managed server in those operations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2046) Order of XSD protocol elements and protocol attributes is arbitrary

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2046?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on JGRP-2046: -------------------------------------- This is pretty awesome, here is a report I can now make of configuration differences between 3.6.8.Final and 4.0.0-SNAPSHOT: https://gist.github.com/rhusar/67abf87afdd556700a424b35772ad67a > Order of XSD protocol elements and protocol attributes is arbitrary > ------------------------------------------------------------------- > > Key: JGRP-2046 > URL: https://issues.jboss.org/browse/JGRP-2046 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.8 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > While fixing JGRP-2037 I realized that the order in the XSD is completely random/arbitrary/undefined. The order relies on hash-based collections, undefined order from reflection classes, etc. > This makes impossible to compare XSDs from other builds or other versions to see what changed. > Probably the best approach is to sort both collections with classes and collections with attributes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2046) Order of XSD protocol elements and protocol attributes is arbitrary

by Radoslav Husar (JIRA)

Radoslav Husar created JGRP-2046: ------------------------------------ Summary: Order of XSD protocol elements and protocol attributes is arbitrary Key: JGRP-2046 URL: https://issues.jboss.org/browse/JGRP-2046 Project: JGroups Issue Type: Enhancement Affects Versions: 3.6.8 Reporter: Radoslav Husar Assignee: Bela Ban While fixing JGRP-2037 I realized that the order in the XSD is completely random/arbitrary/undefined. The order relies on hash-based collections, undefined order from reflection classes, etc. This makes impossible to compare XSDs from other builds or other versions to see what changed. Probably the best approach is to sort both collections with classes and collections with attributes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2046) Order of XSD protocol elements and protocol attributes is arbitrary

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2046?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned JGRP-2046: ------------------------------------ Assignee: Radoslav Husar (was: Bela Ban) > Order of XSD protocol elements and protocol attributes is arbitrary > ------------------------------------------------------------------- > > Key: JGRP-2046 > URL: https://issues.jboss.org/browse/JGRP-2046 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.8 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > While fixing JGRP-2037 I realized that the order in the XSD is completely random/arbitrary/undefined. The order relies on hash-based collections, undefined order from reflection classes, etc. > This makes impossible to compare XSDs from other builds or other versions to see what changed. > Probably the best approach is to sort both collections with classes and collections with attributes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1052) Add server-config parameter to :reload op

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugi... ] Kabir Khan reopened WFCORE-1052: -------------------------------- > Add server-config parameter to :reload op > ----------------------------------------- > > Key: WFCORE-1052 > URL: https://issues.jboss.org/browse/WFCORE-1052 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha1 > > > {code} > [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml  looks for that file in the snapshots directory > [13:48] Kabir Khan: > [standalone@localhost:9990 /] :list-snapshots > { > "outcome" => "success", > "result" => { > "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot", > "names" => [ > "20151013-134523280standalone.xml", > "20151013-134726769standalone.xml" > ] > } > } > Show less > [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation > {code} > Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail. > For a domain server, we should not have the server-config parameter. > We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1052) Add server-config parameter to :reload op

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1052: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1498 (was: https://github.com/wildfly/wildfly-core/pull/1196) > Add server-config parameter to :reload op > ----------------------------------------- > > Key: WFCORE-1052 > URL: https://issues.jboss.org/browse/WFCORE-1052 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha1 > > > {code} > [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml  looks for that file in the snapshots directory > [13:48] Kabir Khan: > [standalone@localhost:9990 /] :list-snapshots > { > "outcome" => "success", > "result" => { > "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot", > "names" => [ > "20151013-134523280standalone.xml", > "20151013-134726769standalone.xml" > ] > } > } > Show less > [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation > {code} > Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail. > For a domain server, we should not have the server-config parameter. > We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation. -- 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 April 2016