December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-296) Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFCORE-296: ----------------------------------------- That would be under REMJMX-85 > Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > --------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-296 > URL: https://issues.jboss.org/browse/WFCORE-296 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > From [~dmlloyd] > {quote} > When we have multi-layer protocol going on, the URI scheme we should use > is like this: > outer+middle+inner:// > {quote} > Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > The existing schemes will be needed for backwards compatibility but somehow deprecated. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-210?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-210: ------------------------------------------------ Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1159709|https://bugzilla.redhat.com/show_bug.cgi?id=1159709] from ON_QA to VERIFIED > IO error during deployment scanning triggers undeployment > --------------------------------------------------------- > > Key: WFCORE-210 > URL: https://issues.jboss.org/browse/WFCORE-210 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications. > This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs. > It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1904?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1904: --------------------------- Description: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. ** {{xmit_interval}} can be reused as interval * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) ** When the current seqno hasn't changed for N times, don't send the highest seqno * When messages are sent, the task should not run either * It should also be possible to trigger the sending programmatically, or via JMX was: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) ** When messages are sent, the task should not run either * It should also be possible to trigger the sending programmatically, or via JMX > NAKACK2: retransmit the last-message-missing sooner > --------------------------------------------------- > > Key: JGRP-1904 > URL: https://issues.jboss.org/browse/JGRP-1904 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. > Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. > When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. > So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. > We therefore need a quicker way to detect and retransmit missing messages. > h5. Solution > * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. > ** {{xmit_interval}} can be reused as interval > * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission > * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > ** When the current seqno hasn't changed for N times, don't send the highest seqno > * When messages are sent, the task should not run either > * It should also be possible to trigger the sending programmatically, or via JMX -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1904?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1904: --------------------------- Description: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) ** When messages are sent, the task should not run either * It should also be possible to trigger the sending programmatically, or via JMX was: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) * It should also be possible to trigger the sending programmatically, or via JMX > NAKACK2: retransmit the last-message-missing sooner > --------------------------------------------------- > > Key: JGRP-1904 > URL: https://issues.jboss.org/browse/JGRP-1904 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. > Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. > When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. > So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. > We therefore need a quicker way to detect and retransmit missing messages. > h5. Solution > * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. > * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission > * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > ** When messages are sent, the task should not run either > * It should also be possible to trigger the sending programmatically, or via JMX -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[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)

9 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)

9 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)

9 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)

9 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)

9 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)

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