[JBoss JIRA] (WFCORE-863) CLI keeps reminding it's disconnected after every executed command when it's disconnected
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-863?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky updated WFCORE-863:
-------------------------------------
Affects Version/s: 2.0.0.Alpha12
> CLI keeps reminding it's disconnected after every executed command when it's disconnected
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-863
> URL: https://issues.jboss.org/browse/WFCORE-863
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha12
> Reporter: Alexey Loubyansky
> Assignee: Joe Wertz
>
> 'You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.' This line is printed by CLIAeshConsoleCallback() after every entered line when the CLI is not connected to the controller.
> It used to be printed at the beginning of the session and in case the CLI looses the connection.
> I wouldn't insist on keeping it like it used to be, btw. But I guess it makes sense to have some hint-warning like that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFCORE-864) CLI echo command doesn't echo variables any more
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-864:
----------------------------------------
Summary: CLI echo command doesn't echo variables any more
Key: WFCORE-864
URL: https://issues.jboss.org/browse/WFCORE-864
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 2.0.0.Alpha12
Reporter: Alexey Loubyansky
Assignee: Joe Wertz
This CLI log is produced by wildfly-core-2.0.0.Alpha11
[olubyans@fedovo bin]$ ./jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] echo
[disconnected /] set a=aa
[disconnected /] echo $a
aa
And this one is the current one (with the new Aesh)
[disconnected /] set a=aa
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] echo $a
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /]
I've verified that the variables are set with set command. I guess Aesh is handling $xxx itself and just replaces them with nothing, as Aesh is unaware of the CLI variables.
There is EchoTestCase but, as it's not interactive, Aesh does not get involved there, I guess.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-5012) Resource alias operation inconsistencies
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5012?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-5012:
----------------------------------
Another part of this, is that there is nothing in r-r-d's output indicating that this is an alias. So perhaps that is needed, and if something is an alias, should we put in both the 'real' and 'alias' addresses?
> Resource alias operation inconsistencies
> ----------------------------------------
>
> Key: WFLY-5012
> URL: https://issues.jboss.org/browse/WFLY-5012
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Kabir Khan
> Priority: Blocker
> Fix For: 10.0.0.Beta1
>
>
> Formlery we could request the ../eviction=EVICTION resource. I assume that with the resource name change a transformer kicks that redirects the request to the ../component" => "eviction resource. The response header however contains the wrong address, which prevents clients to correlate the request with the response.
> *In HAL this breaks the access control mechanism.*
> {noformat}
> [domain@localhost:9990 /] /profile=full/subsystem=infinispan/cache-container=*/invalidation-cache=*/eviction=EVICTION:read-resource-description
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("profile" => "full"),
> ("subsystem" => "infinispan"),
> ("cache-container" => "*"),
> ("invalidation-cache" => "*"),
> ("component" => "eviction")
> ],
> "outcome" => "success",
> [...]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFCORE-863) CLI keeps reminding it's disconnected after every executed command when it's disconnected
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-863:
----------------------------------------
Summary: CLI keeps reminding it's disconnected after every executed command when it's disconnected
Key: WFCORE-863
URL: https://issues.jboss.org/browse/WFCORE-863
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Alexey Loubyansky
Assignee: Joe Wertz
'You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.' This line is printed by CLIAeshConsoleCallback() after every entered line when the CLI is not connected to the controller.
It used to be printed at the beginning of the session and in case the CLI looses the connection.
I wouldn't insist on keeping it like it used to be, btw. But I guess it makes sense to have some hint-warning like that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFCORE-862) MBeanServer returns MBean names that do not match filter
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-862?page=com.atlassian.jira.plugin... ]
Kabir Khan moved WFLY-5016 to WFCORE-862:
-----------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-862 (was: WFLY-5016)
Affects Version/s: 2.0.0.Alpha12
(was: 9.0.0.Final)
(was: 9.0.1.Final)
Component/s: JMX
(was: JMX)
Fix Version/s: 2.0.0.Beta1
(was: 9.x.x TBD)
> MBeanServer returns MBean names that do not match filter
> --------------------------------------------------------
>
> Key: WFCORE-862
> URL: https://issues.jboss.org/browse/WFCORE-862
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Affects Versions: 2.0.0.Alpha12
> Reporter: Thomas Diesler
> Assignee: Kabir Khan
> Fix For: 2.0.0.Beta1
>
>
> This code
> {code}
> MBeanServer server = ManagementFactory.getPlatformMBeanServer();
> for (ObjectName oname : server.queryNames(new ObjectName("*:type=context,*"), null)) {
> System.out.println(oname);
> }
> {code}
> gives
> {code}
> 16:51:25,842 INFO [stdout] (pool-3-thread-1) org.apache.camel:context=swagger-test,type=context,name="swagger-test"
> 16:51:25,842 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEServer,name=default
> 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=JVM,name=default,J2EEServer=default
> 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEDomain,name=jboss.jsr77
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bram Klein Gunnewiek (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bram Klein Gunnewiek commented on JGRP-1944:
--------------------------------------------
Strange, I will test it again today to see if I can reproduce it or find out why your results are different then mine. Tnx for picking this up so quickly.
> jgroups does not recover properly when using UDP after ifdown / ifup
> --------------------------------------------------------------------
>
> Key: JGRP-1944
> URL: https://issues.jboss.org/browse/JGRP-1944
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Linux Ubutun 14.04 where the network cards are configured as bridges:
> auto bridge0
> iface bridge0 inet dhcp
> bridge_ports eth1
> bridge_stp off
> bridge_fd 0
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 3.6.5
>
> Attachments: AutoRecoverMulticast.java
>
>
> When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry .
> When we use TCP + MPING we see the stacktraces we had previously with UDP:
> 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request
> java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
> at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
> at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured)
> A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1944:
--------------------------------
I cannot reproduce this, as the merge always worked (10-30s after ifconfig up)
> jgroups does not recover properly when using UDP after ifdown / ifup
> --------------------------------------------------------------------
>
> Key: JGRP-1944
> URL: https://issues.jboss.org/browse/JGRP-1944
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Linux Ubutun 14.04 where the network cards are configured as bridges:
> auto bridge0
> iface bridge0 inet dhcp
> bridge_ports eth1
> bridge_stp off
> bridge_fd 0
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 3.6.5
>
> Attachments: AutoRecoverMulticast.java
>
>
> When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry .
> When we use TCP + MPING we see the stacktraces we had previously with UDP:
> 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request
> java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
> at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
> at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured)
> A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1944:
--------------------------------
I started 2 instances of the ubuntu image you sent me (the 2nd was a clone of the first) at {{192.168.1.53}} and {{192.168.1.154}}. Next I start 1 ChatDemo instance on each box with {{tcp-config.xml}}.
Then I executed {{sudo ifconfig bridge0 down}} on the first box and wait until the cluster split in 2 subclusters.
Next I executed {{sudo ifconfig bridge0 up}} on the first box.
The subclusters merged back into a cluster of 2, so thsi worked.
Next, I tried the same with {{udp-config.xml}} (copied from the TCP config, but using {{UDP:PING}} instead of {{TCP:MPING}}).
This also worked.
I did get some IOExceptions (network unreachable) on box1, but after ifconfig up, some seconds later, they disappeared and the merge worked.
> jgroups does not recover properly when using UDP after ifdown / ifup
> --------------------------------------------------------------------
>
> Key: JGRP-1944
> URL: https://issues.jboss.org/browse/JGRP-1944
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Linux Ubutun 14.04 where the network cards are configured as bridges:
> auto bridge0
> iface bridge0 inet dhcp
> bridge_ports eth1
> bridge_stp off
> bridge_fd 0
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 3.6.5
>
> Attachments: AutoRecoverMulticast.java
>
>
> When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry .
> When we use TCP + MPING we see the stacktraces we had previously with UDP:
> 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request
> java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
> at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
> at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured)
> A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months