August 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove failed members

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1956?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1956: --------------------------- Fix Version/s: 3.6.5 > S3_PING / FILE_PING: remove failed members > ------------------------------------------ > > Key: JGRP-1956 > URL: https://issues.jboss.org/browse/JGRP-1956 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Karsten Ohme > Assignee: Bela Ban > Fix For: 3.6.5 > > > When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there. > SOLUTION: > - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING) > - On a view change: remove all data that's not in the current view -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-60) Capabilities and requirements in a managed process

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-60?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFCORE-60: ----------------------------------- this should already be done > Capabilities and requirements in a managed process > -------------------------------------------------- > > Key: WFCORE-60 > URL: https://issues.jboss.org/browse/WFCORE-60 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.CR1 > > > Implement the aspects discussed under the "Runtime" section of https://community.jboss.org/docs/DOC-52712 > Add an API to the OperationContext for handlers to publish capabilities and for other handlers to register a requirement for those capabilities and to access the API object associated with the capability. > The registry of capabilities and requirements should be maintained with a semantic equivalent to the resource tree. The registry is copied-on-write, making the copy invisible to concurrently executing operations, and then the copy is published on commit of the operation that modified it. If the operation does not commit, the copy is discarded, so handlers have no need to revert changes they make to the registry. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove failed members

by Karsten Ohme (JIRA)

[ https://issues.jboss.org/browse/JGRP-1956?page=com.atlassian.jira.plugin.... ] Karsten Ohme edited comment on JGRP-1956 at 8/28/15 8:53 PM: ------------------------------------------------------------- This seems to be open again. My developer system is running on local host and is working in single mode. When starting the server a new file in the S3 bucket with the server name plus a random number is created. When the server is restarted, this old address is read from the bucket and a new one is generated. So e.g. after 7 restarts there a 7 servers address stored in the bucket which are tried to be reached when the server is starting up to find other members. I have set the timeout to one second to limit the effect, but the server still tries to connect 10 times before it is switching to single mode. The stale files should be removed somehow, also if the server is crashing or the method for the unique server name calculation should be deterministic. This was working with lower versions than 3.6.4 was (Author: k_o_): This seems to be open again. When starting the server a new file in the S3 bucket with the single DNS name plus a random number is created. When the server is restarted, this old address is read from the bucket and a new one generated. After 7 restarts there a 7 servers address stored in the bucket which are tried to be reached. I have set the timeout to one second to limit the effect, but the server still tries to connect 10 times before it is switching to single mode. The stale files should be removed somehow, also if the server is crashing or the method for the unique server name calculation should be deterministic. This was working with lower versions than 3.6.4 > S3_PING / FILE_PING: remove failed members > ------------------------------------------ > > Key: JGRP-1956 > URL: https://issues.jboss.org/browse/JGRP-1956 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Karsten Ohme > Assignee: Bela Ban > > When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there. > SOLUTION: > - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING) > - On a view change: remove all data that's not in the current view -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove failed members

by Karsten Ohme (JIRA)

[ https://issues.jboss.org/browse/JGRP-1956?page=com.atlassian.jira.plugin.... ] Karsten Ohme updated JGRP-1956: ------------------------------- Issue Type: Bug (was: Feature Request) Fix Version/s: (was: 2.10) (was: 2.6.16) Affects Version/s: 3.6.4 This seems to be open again. When starting the server a new file in the S3 bucket with the single DNS name plus a random number is created. When the server is restarted, this old address is read from the bucket and a new one generated. After 7 restarts there a 7 servers address stored in the bucket which are tried to be reached. I have set the timeout to one second to limit the effect, but the server still tries to connect 10 times before it is switching to single mode. The stale files should be removed somehow, also if the server is crashing or the method for the unique server name calculation should be deterministic. This was working with lower versions than 3.6.4 > S3_PING / FILE_PING: remove failed members > ------------------------------------------ > > Key: JGRP-1956 > URL: https://issues.jboss.org/browse/JGRP-1956 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Karsten Ohme > Assignee: Bela Ban > > When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there. > SOLUTION: > - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING) > - On a view change: remove all data that's not in the current view -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove failed members

by Karsten Ohme (JIRA)

Karsten Ohme created JGRP-1956: ---------------------------------- Summary: S3_PING / FILE_PING: remove failed members Key: JGRP-1956 URL: https://issues.jboss.org/browse/JGRP-1956 Project: JGroups Issue Type: Feature Request Reporter: Karsten Ohme Assignee: Bela Ban Fix For: 2.6.16, 2.10 When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there. SOLUTION: - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING) - On a view change: remove all data that's not in the current view -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-273: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 2.0.0.CR1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-60) Capabilities and requirements in a managed process

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-60?page=com.atlassian.jira.plugin.... ] James Perkins updated WFCORE-60: -------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Capabilities and requirements in a managed process > -------------------------------------------------- > > Key: WFCORE-60 > URL: https://issues.jboss.org/browse/WFCORE-60 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.CR1 > > > Implement the aspects discussed under the "Runtime" section of https://community.jboss.org/docs/DOC-52712 > Add an API to the OperationContext for handlers to publish capabilities and for other handlers to register a requirement for those capabilities and to access the API object associated with the capability. > The registry of capabilities and requirements should be maintained with a semantic equivalent to the resource tree. The registry is copied-on-write, making the copy invisible to concurrently executing operations, and then the copy is published on commit of the operation that modified it. If the operation does not commit, the copy is discarded, so handlers have no need to revert changes they make to the registry. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-54) Add Keycloak authentication/authorization to http management endpoint

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-54?page=com.atlassian.jira.plugin.... ] James Perkins updated WFCORE-54: -------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Add Keycloak authentication/authorization to http management endpoint > --------------------------------------------------------------------- > > Key: WFCORE-54 > URL: https://issues.jboss.org/browse/WFCORE-54 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 2.0.0.CR1 > > > This is here to track the core changes needed for WFLY-3591. See that jira for details. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-603) Simplify working with complex attributes

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-603?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-603: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Simplify working with complex attributes > ---------------------------------------- > > Key: WFCORE-603 > URL: https://issues.jboss.org/browse/WFCORE-603 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 2.0.0.CR1 > > > This is umbrella issue for all complex attributes related enhancements and simplifications. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-471) pre/post cli-scripts for AS patching feature

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-471?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-471: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > pre/post cli-scripts for AS patching feature > -------------------------------------------- > > Key: WFCORE-471 > URL: https://issues.jboss.org/browse/WFCORE-471 > Project: WildFly Core > Issue Type: Feature Request > Components: Patching , Scripts > Reporter: Nicklas Karlsson > Assignee: Alexey Loubyansky > Fix For: 2.0.0.CR1 > > > It would be handy to be able to attach pre/post CLI scripts to be applied for an AS patch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 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 August 2015