December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1902) Simplify failure detection and merge timeout configuration

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1902?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1902: --------------------------- Priority: Minor (was: Major) > Simplify failure detection and merge timeout configuration > ---------------------------------------------------------- > > Key: JGRP-1902 > URL: https://issues.jboss.org/browse/JGRP-1902 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.1, 4.0 > > > FD/FD_ALL/FD_ALL2/FD_SOCK javadoc doesn't give any guidance as to how long it would take to detect a leaving member. MERGE2/MERGE3 javadoc also doesn't say how much it would take to detect that the network has healed. > For an example of how misleading the current settings can be, I have seen MERGE3 take more than 20s to merge two partitions with min_interval=1000 and max_interval=5000. FD also detects a leaver after {{timeout * max_tries}} in the best case, and twice that if 2 consecutive nodes (in the members list) leave at the same time. > The maximum time it takes to detect a leaver is of particular interest to Infinispan users, because Infinispan is supposed to protect against nodes leaving. But if the users don't configure a high enough RPC timeout in Infinispan, we don't get to detect the node leaving. > Ideally, the user should be able to specify a maximum detection time, and the protocol should adjust the existing settings to meet that (most of the time). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-239) Socket binding remove does not respect allow-resource-service-restart

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-239?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-239: ------------------------------------ Component/s: Domain Management > Socket binding remove does not respect allow-resource-service-restart > --------------------------------------------------------------------- > > Key: WFCORE-239 > URL: https://issues.jboss.org/browse/WFCORE-239 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stuart Douglas > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-287) Provide a 'map-reduce' operation to execute domain wide queries on the server side

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-287?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-287: ------------------------------------ Component/s: Domain Management > Provide a 'map-reduce' operation to execute domain wide queries on the server side > ---------------------------------------------------------------------------------- > > Key: WFCORE-287 > URL: https://issues.jboss.org/browse/WFCORE-287 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 1.0.0.Beta1 > > > See https://github.com/hpehl/map-reduce > {code:java} > ModelNode address = new ModelNode(); > address.add("profile", "*") > .add("subsystem", "datasources") > .add("data-source", "*"); > ModelNode filter = new ModelNode(); > filter.add("driver-name", "h2") > .add("enabled", true); > ModelNode op = new ModelNode(); > op.get(OP).set(MAP_REDUCE); > op.get(ADDRESS_TEMPLATE).set(address); > op.get(FILTER).set(filter); > // To return datasources where (driver-name == h2 || enabled == true) use > // op.get(FILTER_CONJUNCT).set(false); > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-179) Support nested expressions in management API and deployment descriptors

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-179?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-179: ------------------------------------ Component/s: Domain Management > Support nested expressions in management API and deployment descriptors > ----------------------------------------------------------------------- > > Key: WFCORE-179 > URL: https://issues.jboss.org/browse/WFCORE-179 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Users have requested support for expressions such as: > {code} > ${VAULT::oracle::${me}::0} > {code} > where "me" is a system property. > Allows externalization of the vault attribute name. > This will likely require JBMETA changes as well, as the deployment level stuff is there. > I want this to be a generic thing, not just a specific solution to the above example. So, something like, given a string, find the innermost expression, resolve it and then repeat until the input equals the output (i.e. there are no more expressions.) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2292) Add config option to fail deployment if private API is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2292?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-2292: ----------------------------------- Component/s: Domain Management > Add config option to fail deployment if private API is used > ----------------------------------------------------------- > > Key: WFLY-2292 > URL: https://issues.jboss.org/browse/WFLY-2292 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Pete Muir > Assignee: Brian Stansberry > Fix For: 9.0.0.Beta1 > > > This would allow users to have continuous integration jobs check if their app uses a private API by mistake, and have the job fail if it does. > Needed to automate the check that quickstarts only use public API. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-437) Add config option to fail deployment if private API is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-437?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-2292 to WFCORE-437: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-437 (was: WFLY-2292) Component/s: Domain Management (was: Domain Management) Fix Version/s: (was: 9.0.0.Beta1) > Add config option to fail deployment if private API is used > ----------------------------------------------------------- > > Key: WFCORE-437 > URL: https://issues.jboss.org/browse/WFCORE-437 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Pete Muir > Assignee: Brian Stansberry > > This would allow users to have continuous integration jobs check if their app uses a private API by mistake, and have the job fail if it does. > Needed to automate the check that quickstarts only use public API. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3019) Shutdown on startup error

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3019?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3019: ----------------------------------- Component/s: Domain Management > Shutdown on startup error > ------------------------- > > Key: WFLY-3019 > URL: https://issues.jboss.org/browse/WFLY-3019 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Takayoshi Kimura > > Currently WildFly starts and up running although it got critical errors during boot. > For example, 8080 port is being used by the other process and undertow subsystem was not functioning, transaction manager and logging subsystems are failed to boot due to file permission error, or someone started the instance twice by mistake. > It would be nice if we can have an option to trigger shutdown the non-healthy instance in these boot error situations, for subsystem level errors and for deployment errors. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-436) Shutdown on startup error

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-436?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-3019 to WFCORE-436: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-436 (was: WFLY-3019) Affects Version/s: (was: 8.0.0.Final) Component/s: Domain Management (was: Domain Management) > Shutdown on startup error > ------------------------- > > Key: WFCORE-436 > URL: https://issues.jboss.org/browse/WFCORE-436 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Takayoshi Kimura > > Currently WildFly starts and up running although it got critical errors during boot. > For example, 8080 port is being used by the other process and undertow subsystem was not functioning, transaction manager and logging subsystems are failed to boot due to file permission error, or someone started the instance twice by mistake. > It would be nice if we can have an option to trigger shutdown the non-healthy instance in these boot error situations, for subsystem level errors and for deployment errors. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-435) Add MBean server support to Management console

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-435?page=com.atlassian.jira.plugin... ] Brian Stansberry moved WFLY-3426 to WFCORE-435: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-435 (was: WFLY-3426) > Add MBean server support to Management console > ---------------------------------------------- > > Key: WFCORE-435 > URL: https://issues.jboss.org/browse/WFCORE-435 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Sebastian Łaskawiec > Assignee: Jason Greene > Priority: Minor > > In JBoss 5.x server there was a web based tool for managing JMX Beans. Currently this functionality is supported via bundled JConsole. It would be convenient to have such functionality based on HTTP Web Management panel. > As discussed on email thread (subject: "JMX Console over Web Admin Console") it should be placed a part of standard management resource tree or in context of HTTP management interface. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3653) Managed Executors: unhandled exceptions should be logged

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3653?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3653: ----------------------------------- Component/s: EE > Managed Executors: unhandled exceptions should be logged > -------------------------------------------------------- > > Key: WFLY-3653 > URL: https://issues.jboss.org/browse/WFLY-3653 > Project: WildFly > Issue Type: Enhancement > Components: EE > Affects Versions: 8.1.0.Final > Reporter: Rich DiCroce > Assignee: Jason Greene > > If you submit a task to a ManagedExecutorService, and the task throws an exception that propagates out of the task, the exception is not logged anywhere. Obviously, developers can simply wrap their task's code with a try-catch, but it would be nice if that were not needed. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 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 December 2014