[JBoss JIRA] (WFCORE-1614) Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1614?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1614:
----------------------------------------------
That is a good point, I am looking at only echoing only the executed branch.
> Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1614
> URL: https://issues.jboss.org/browse/WFCORE-1614
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha3
>
> Attachments: test.cli
>
>
> We are proposing here to add a Cli option (command line option and an XML element) to make the CLI to echo the command and its options in non interactive mode. This will help to match a given command and its output.
> For example, the "ls -l" command output would be:
> [standalone@localhost:9990 /] ls -l
> ATTRIBUTE VALUE TYPE
> launch-type STANDALONE STRING
> management-major-version 5 INT
> management-micro-version 0 INT
> management-minor-version 0 INT
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6776) Unclear error message when creating multiple thread pools of the same type for a workmanager
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6776?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-6776:
-------------------------------
{{long-running-threads/short-running-threads}} in JCA workmanager uses {{BoundedQueueThreadPoolResourceDefinition}} in {{threads}} subsystem of wildfly-core to operate.
It needs changes in wildfly-core to be able to extend the ability to check the {{long-running-threads/short-running-threads}} within same workmanager, the constructor of {{BoundedQueueThreadPoolResourceDefinition}} is private now, which needs to be changed I think.
> Unclear error message when creating multiple thread pools of the same type for a workmanager
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-6776
> URL: https://issues.jboss.org/browse/WFLY-6776
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Lin Gao
> Assignee: Lin Gao
>
> When there is already a long-running thread pool for a work manager and you try to create another one:
> {{/subsystem=jca/workmanager=default/long-running-threads=custom:add(max-threads=30, queue-length=30)}}
> you only get an opaque error message:
> {{"failure-description" => "WFLYCTL0086: Failed to persist configuration change: WFLYCTL0084: Failed to marshal configuration",}} with a, also useless, {{java.lang.IllegalArgumentException}} in the server log.
> It should be more obvious that the error is that you cannot create two long-running thread pools
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2075) SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2075?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2075:
---------------------------
Fix Version/s: 3.6.11
(was: 3.6.10)
> SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers
> -------------------------------------------------------
>
> Key: JGRP-2075
> URL: https://issues.jboss.org/browse/JGRP-2075
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> Currently we use WeakHashMap, but should not, reasons outlined below. We could replace it with a LazyRemovalCache. Andrew's email refers to SecretKeys but this probably also applies to Ciphers.
> Andrew Haley's email:
> {quote}
> TL/DR: Please don't use WeakReferences, SoftReferences, etc. to cache
> any data which might point to native memory. In particular, never do
> this with instances of java.security.Key. Instead, implement either
> some kind of ageing strategy or a fixed-size cache.
> ...
> This is a warning to anybody who might cache crypto keys.
> A customer has been having problems with the exhaustion of native
> memory before the Java heap is full. It was fun trying to track down
> the cause, but it's now happened several times to several customers,
> and it's a serious problem for real-world usage in app servers.
> PKCS#11 is a standard way to communicate between applications and
> crypto libraries. There is a Java crypto provider which supports
> PKCS#11. Some of our customers must use this provider in order to get
> FIPS certification.
> The problem is this:
> A crypto key is a buffer in memory, allocated by the PKCS#11 native
> library. It's accessed via a handle which is stored as an integer
> field in a Java object. This Java object is a PhantomReference, so
> when the garbage collector detects that a crypto key is no longer
> reachable it is closed and the associated native memory is freed.
> Modern garbage collectors don't much bother to process objects in the
> old generation because it's not usually worthwhile. Thus, crypto keys
> don't get recycled very quickly. They can pile up in the old
> generation. This isn't a problem for the Java heap because the
> objects containing the references to crypto keys are very small.
> Unfortunately, the native side of a crypto key is much bigger, maybe
> up to a thousand times bigger. So if we have 4000 stale crypto keys
> in the heap that's not a problem, a few kbytes. But the native memory
> may be a megabyte.
> This problem is made even worse by Tomcat because it uses
> SoftReferences to cache crypto keys. SoftReferences are processed
> lazily, and maybe not at all until the Java heap runs out of memory.
> Unfortunately it doesn't, but the machine runs out of native memory
> instead.
> We could solve this simply by making instances of PKCS#11 keys really
> big Java objects by padding with dummy fields. Then, the GC would
> collect them quickly. This does work but it seriously impacts
> performance. Also, we could tweak the garbage collectors to clear out
> stale references more enthusiastically, but this impacts performance
> even more. There are some controls with the G1 collector which
> process SoftReferences more aggressively and these help, but again at
> the cost of performance.
> Finally: the Shanandoah collector we're working on handles this
> problem much better than the older collectors, but it's some
> way off.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2034) SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2034?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2034:
---------------------------
Fix Version/s: 3.6.11
(was: 3.6.10)
> SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
> ------------------------------------------------------------------------------------------
>
> Key: JGRP-2034
> URL: https://issues.jboss.org/browse/JGRP-2034
> Project: JGroups
> Issue Type: Bug
> Reporter: Ivan Straka
> Assignee: Tristan Tarrant
> Fix For: 3.6.11
>
>
> We see these two tests failing on IBM jdk 1.8
> org.jgroups.protocols.SASLTest-functional
> org.jgroups.protocols.SASL_SimpleAuthorizingCallbackTest-functional
> This issue may be related to https://issues.jboss.org/browse/JGRP-1993 somehow.
> There is standard output of tests.
> {code}
> ------------- testSASLDigestMD5 -----------
> -------------------------------------------------------------------
> GMS: address=A, cluster=SaslTest
> -------------------------------------------------------------------
> 521823 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
> 521823 [DEBUG] GMS: A: installing view [A|0] (1) [A]
> 521823 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> -------------------------------------------------------------------
> GMS: address=B, cluster=SaslTest
> -------------------------------------------------------------------
> 521825 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
> 521826 [DEBUG] GMS: B: sending JOIN(B) to A
> 521826 [TRACE] SASL: B: received CHALLENGE from A
> 521827 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 524826 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
> 524827 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
> 524827 [DEBUG] GMS: B: sending JOIN(B) to A
> 524828 [TRACE] SASL: B: received CHALLENGE from A
> 524828 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 526826 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@ad737f58
> ------------- testSASLDigestMD5Failure -----------
> -------------------------------------------------------------------
> GMS: address=A, cluster=SaslTest
> -------------------------------------------------------------------
> 529863 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
> 529864 [DEBUG] GMS: A: installing view [A|0] (1) [A]
> 529864 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> -------------------------------------------------------------------
> GMS: address=B, cluster=SaslTest
> -------------------------------------------------------------------
> 529866 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
> 529866 [DEBUG] GMS: B: sending JOIN(B) to A
> 529867 [TRACE] SASL: B: received CHALLENGE from A
> 529867 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 532867 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
> 532867 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
> 532867 [DEBUG] GMS: B: sending JOIN(B) to A
> 532868 [TRACE] SASL: B: received CHALLENGE from A
> 532869 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 534867 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@6f6c2511
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1614) Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1614?page=com.atlassian.jira.plugi... ]
Petr Kremensky updated WFCORE-1614:
-----------------------------------
Attachment: test.cli
Testing script.
{noformat}
./jboss-cli.sh --echo-command --file=test.cli
{noformat}
> Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1614
> URL: https://issues.jboss.org/browse/WFCORE-1614
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha3
>
> Attachments: test.cli
>
>
> We are proposing here to add a Cli option (command line option and an XML element) to make the CLI to echo the command and its options in non interactive mode. This will help to match a given command and its output.
> For example, the "ls -l" command output would be:
> [standalone@localhost:9990 /] ls -l
> ATTRIBUTE VALUE TYPE
> launch-type STANDALONE STRING
> management-major-version 5 INT
> management-micro-version 0 INT
> management-minor-version 0 INT
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1614) Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1614?page=com.atlassian.jira.plugi... ]
Petr Kremensky edited comment on WFCORE-1614 at 6/27/16 4:00 AM:
-----------------------------------------------------------------
Testing script attached.
{noformat}
./jboss-cli.sh --echo-command --file=test.cli
{noformat}
was (Author: pkremens):
Testing script.
{noformat}
./jboss-cli.sh --echo-command --file=test.cli
{noformat}
> Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1614
> URL: https://issues.jboss.org/browse/WFCORE-1614
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha3
>
> Attachments: test.cli
>
>
> We are proposing here to add a Cli option (command line option and an XML element) to make the CLI to echo the command and its options in non interactive mode. This will help to match a given command and its output.
> For example, the "ls -l" command output would be:
> [standalone@localhost:9990 /] ls -l
> ATTRIBUTE VALUE TYPE
> launch-type STANDALONE STRING
> management-major-version 5 INT
> management-micro-version 0 INT
> management-minor-version 0 INT
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1614) Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1614?page=com.atlassian.jira.plugi... ]
Petr Kremensky commented on WFCORE-1614:
----------------------------------------
I see a problem with control flow statements usage, as all commands are printed first, creating a lot of noise in output.
It could be quite difficult to re-create a problematic situation using the echoed commands (we should take into account that customer's scripts could have thousand of lines) - see 'set prop', reload, stop-embedded-server, asdqwe-error from else branch which was not executed.
{noformat}
[pkremens@dlocalhost]$ cat test.cli
embed-server
try
:read-attribute(name=foo)
catch
/system-property=catch:add(value=bar)
finally
/system-property=finally:add(value=bar)
end-try
/system-property=*:read-resource
if (outcome == success) of /system-property=catch:read-attribute(name=value)
set prop=Catch\ block\ was\ executed
/system-property=finally:write-attribute(name=value, value=if)
else
set prop=Catch\ block\ wasn\'t\ executed
reload
stop-embedded-server
asdqwe-error
/system-property=finally:write-attribute(name=value, value=else)
end-if
reload
stop-embedded-server
{noformat}
Run the script
{noformat}
./jboss-cli.sh --echo-command --file=/home/pkremens/workspace/wildfly-core-3.0.0.Alpha3-SNAPSHOT/bin/test.cli
[disconnected /] embed-server
[standalone@embedded /] try
[standalone@embedded /] :read-attribute(name=foo)
[standalone@embedded /] catch
[standalone@embedded /] /system-property=catch:add(value=bar)
[standalone@embedded /] finally
[standalone@embedded /] /system-property=finally:add(value=bar)
[standalone@embedded /] end-try
[standalone@embedded /] :read-attribute(name=foo)
[standalone@embedded /] /system-property=catch:add(value=bar)
{"outcome" => "success"}
[standalone@embedded /] /system-property=finally:add(value=bar)
{"outcome" => "success"}
[standalone@embedded /] /system-property=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("system-property" => "catch")],
"outcome" => "success",
"result" => {"value" => "bar"}
},
{
"address" => [("system-property" => "finally")],
"outcome" => "success",
"result" => {"value" => "bar"}
}
]
}
[standalone@embedded /] if (outcome == success) of /system-property=catch:read-attribute(name=value)
[standalone@embedded /] set prop=Catch\ block\ was\ executed
[standalone@embedded /] /system-property=finally:write-attribute(name=value, value=if)
[standalone@embedded /] else
[standalone@embedded /] set prop=Catch\ block\ wasn\'t\ executed
[standalone@embedded /] reload
[standalone@embedded /] stop-embedded-server
[standalone@embedded /] asdqwe-error
[standalone@embedded /] /system-property=finally:write-attribute(name=value, value=else)
[standalone@embedded /] end-if
[standalone@embedded /] set prop=Catch\ block\ was\ executed
[standalone@embedded /] /system-property=finally:write-attribute(name=value, value=if)
{"outcome" => "success"}
[standalone@embedded /] reload
[standalone@embedded /] stop-embedded-server
{noformat}
Bash debugging
{noformat}
[pkremens@dlocalhost]$ cat test.sh
set -x
if true ; then
echo yes
TEST=ANO
else
echo no
TEST=NE
fi
set +x
{noformat}
else branch is not echoed
{noformat}
[pkremens@dlocalhost]$ ./test.sh
++ true
++ echo yes
yes
++ TEST=ANO
++ set +x
{noformat}
> Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1614
> URL: https://issues.jboss.org/browse/WFCORE-1614
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha3
>
>
> We are proposing here to add a Cli option (command line option and an XML element) to make the CLI to echo the command and its options in non interactive mode. This will help to match a given command and its output.
> For example, the "ls -l" command output would be:
> [standalone@localhost:9990 /] ls -l
> ATTRIBUTE VALUE TYPE
> launch-type STANDALONE STRING
> management-major-version 5 INT
> management-micro-version 0 INT
> management-minor-version 0 INT
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6762) Is Network Disabling on a Node, a valid test scenario for testing Wildfly Cluster Failover?
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-6762:
-----------------------------------
Description:
In your mail related to WFLY-6749 you has said the below :-
*The default stack contains the following failure detection protocols:
FD_SOCK
FD_ALL
These protocols are described here:
http://www.jgroups.org/manual/index.html#FailureDetection
I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
e.g.
<protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
*
Thanks for the quick response on WFLY-6749.
Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
Thanks,
Preeta
was:
In your mail related to WFLY-6749 you has said the below :-
*The default stack contains the following failure detection protocols:
FD_SOCK
FD_ALL
These protocols are described here:
http://www.jgroups.org/manual/index.html#FailureDetection
I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
e.g.
<protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
*
Thanks for the quick response on WFLY-6749.
Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
Thanks,
Preeta
Summary: Is Network Disabling on a Node, a valid test scenario for testing Wildfly Cluster Failover? (was: Is Network Disabling on a Node, a valid test scenario for testing Cluster Failover)
> Is Network Disabling on a Node, a valid test scenario for testing Wildfly Cluster Failover?
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6762
> URL: https://issues.jboss.org/browse/WFLY-6762
> Project: WildFly
> Issue Type: CTS Challenge
> Components: Clustering
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Paul Ferraro
> Priority: Critical
>
> In your mail related to WFLY-6749 you has said the below :-
> *The default stack contains the following failure detection protocols:
> FD_SOCK
> FD_ALL
> These protocols are described here:
> http://www.jgroups.org/manual/index.html#FailureDetection
> I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property.
> e.g.
> <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol>
> *
> Thanks for the quick response on WFLY-6749.
> Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster.
> The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster.
> However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node.
> Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster.
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months