[JBoss JIRA] (WFCORE-1377) WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1377?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1377:
------------------------------------------
Sorry, never mind; already closed! :)
> WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API
> -----------------------------------------------------------------------
>
> Key: WFCORE-1377
> URL: https://issues.jboss.org/browse/WFCORE-1377
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.CR1
> Reporter: Martin Choma
> Assignee: Brian Stansberry
>
> Unable to get server-state using http management API
> {noformat}
> [mchoma@localhost bin]$ curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server" : "server-one" }]], "name" : "server-state","json.pretty":1}' -u admin:admin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Tue, 16 Feb 2016 08:09:39 GMT
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> Authentication-Info: nextnonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",qop="auth",rspauth="8e575a86f8dae40426abd49bbc8f8b8a",cnonce="YmNiNmM4YjA0NmZlYjQ5MzAwMDAyNjIxMDAwODNhODE=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 131
> Date: Tue, 16 Feb 2016 08:09:39 GMT
> {
> "outcome" : "failed",
> "failure-description" : "WFLYCTL0201: Unknown attribute 'server-state'",
> "rolled-back" : true
> {noformat}
> Running analogous CLI command works OK.
> {noformat}
> [domain@127.0.0.1:9999 /] /host=slave/server=main-three:read-attribute(name=server-state)
> {
> "outcome" => "success",
> "result" => "running"
> }
> {noformat}
> Can't get server status neither with
> {noformat}
> curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server-config" : "server-one" }]], "name" : "status","json.pretty":1}' -u admin:admin
> ...
> "WFLYCTL0201: Unknown attribute 'status'"
> {noformat}
> Issue can be seen in EAP 6, as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1377) WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1377?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1377:
------------------------------------------
Please use the same server for both CLI and HTTP. Is server-one started?
> WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API
> -----------------------------------------------------------------------
>
> Key: WFCORE-1377
> URL: https://issues.jboss.org/browse/WFCORE-1377
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.CR1
> Reporter: Martin Choma
> Assignee: Brian Stansberry
>
> Unable to get server-state using http management API
> {noformat}
> [mchoma@localhost bin]$ curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server" : "server-one" }]], "name" : "server-state","json.pretty":1}' -u admin:admin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Tue, 16 Feb 2016 08:09:39 GMT
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> Authentication-Info: nextnonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",qop="auth",rspauth="8e575a86f8dae40426abd49bbc8f8b8a",cnonce="YmNiNmM4YjA0NmZlYjQ5MzAwMDAyNjIxMDAwODNhODE=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 131
> Date: Tue, 16 Feb 2016 08:09:39 GMT
> {
> "outcome" : "failed",
> "failure-description" : "WFLYCTL0201: Unknown attribute 'server-state'",
> "rolled-back" : true
> {noformat}
> Running analogous CLI command works OK.
> {noformat}
> [domain@127.0.0.1:9999 /] /host=slave/server=main-three:read-attribute(name=server-state)
> {
> "outcome" => "success",
> "result" => "running"
> }
> {noformat}
> Can't get server status neither with
> {noformat}
> curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server-config" : "server-one" }]], "name" : "status","json.pretty":1}' -u admin:admin
> ...
> "WFLYCTL0201: Unknown attribute 'status'"
> {noformat}
> Issue can be seen in EAP 6, as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2014) FILE_PING destination file name can include File.separator characters
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/JGRP-2014?page=com.atlassian.jira.plugin.... ]
Alan Field edited comment on JGRP-2014 at 2/16/16 9:54 AM:
-----------------------------------------------------------
Hey [~belaban], I think I'll take another crack at trying to explain what I think could be done here. The current code replaces "/" and "\" characters with "-" characters. However, this is not a complete list of illegal filename characters for Windows and Linux, and even though JGroups only uses "/" characters in the filename a user can set the node or cluster name and include an illegal character. The question is whether FILE_PING. addressToFilename() should filter out all illegal characters or if FILE_PING.write() should include an error message about these characters if a java.io.FileNotFoundException is thrown. What do you think?
was (Author: afield):
Hey [~belaban], I think I'll take another crack at trying to explain what I think could be done here. The current code replaces {/} and {\} characters with {-} characters. However, this is not a complete list of illegal filename characters for Windows and Linux, and even though JGroups only uses {/} characters in the filename a user can set the node or cluster name and include an illegal character. The question is whether FILE_PING. addressToFilename() should filter out all illegal characters or if FILE_PING.write() should include an error message about these characters if a java.io.FileNotFoundException is thrown. What do you think?
> FILE_PING destination file name can include File.separator characters
> ---------------------------------------------------------------------
>
> Key: JGRP-2014
> URL: https://issues.jboss.org/browse/JGRP-2014
> Project: JGroups
> Issue Type: Bug
> Reporter: Alan Field
> Assignee: Bela Ban
> Fix For: 3.6.8, 4.0
>
>
> I was attempting to use FILE_PING as the discovery protocol with Infinispan server and the following configuration:
> {noformat}
> <protocol type="FILE_PING">
> <property name="location">${jgroups.file.dir:/Users/afield/Documents}</property>
> </protocol>
> {noformat}
> However, the following exceptions occur when I try to start the server:
> {noformat}
> 15:34:41,662 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-11) ISPN000078: Starting JGroups Channel
> 15:34:41,675 ERROR [org.jgroups.protocols.FILE_PING] (MSC service thread 1-11) attempt to write data failed at clustered : clustered.list: java.io.FileNotFoundException: /Users/afield/Documents/clustered/3e5f03c6-c297-474a-cb72-1ca0841f8e5c.afield-osx/clustered.list (No such file or directory)
> at java.io.FileOutputStream.open0(Native Method) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.open(FileOutputStream.java:270) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [rt.jar:1.8.0_72]
> at org.jgroups.protocols.FILE_PING.write(FILE_PING.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FILE_PING.findMembers(FILE_PING.java:116) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:240) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.Discovery.down(Discovery.java:380) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:107) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:255) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:360) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:353) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.down(JChannel.java:791) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel._connect(JChannel.java:564) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.connect(JChannel.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.connect(JChannel.java:279) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:208) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:199) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_72]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_72]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_72]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_72]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:176) [infinispan-commons-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:238) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:583) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:549) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:434) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:105) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:102) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.security.Security.doPrivileged(Security.java:76) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:49) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:110) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:85) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_72]
> {noformat}
> From looking at the code, FILE_PING creates the {{/Users/afield/Documents/clustered}} directory, but the problem is that the {{local_addr}} for the host is {{afield-osx/clustered}}, so {{destination}} is defined as {{75b5c5b8-014d-26ff-c400-5398a96ad3f4.afield-osx/clustered.list}} when {{addressToFilename()}} is called and then the subsequent write fails. File.separator need to be removed or replaced in the {{destination}} variable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6160) Failing RemoteFailoverTestCase#testStatefulFailover when transaction run under JTS
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6160?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6160:
---------------------------------
Steps to Reproduce:
# download JBoss EAP7 ER5
# unzip and set JBOSS_HOME to that directory
# change {{standalone/configuration/standalone-full-ha.xml}} to enable jts transactions
## change attribute {{transactions}} iiop-openjdk subsystem to value {{full}}
## add element {{<jts/>}} under transactions subsystem
# take EAP sources and run integration test
## {{./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Djboss.dist=$JBOSS_HOME -Dtest=RemoteFailoverTestCase#testStatefulFailover}}
was:
. download JBoss EAP7 ER5
. unzip and set JBOSS_HOME to that directory
. change {{standalone/configuration/standalone-full-ha.xml}} to enable jts transactions
.. change attribute {{transactions}} iiop-openjdk subsystem to value {{full}}
.. add element {{<jts/>}} under transactions subsystem
. take EAP sources and run integration test
.. {{./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Djboss.dist=$JBOSS_HOME -Dtest=RemoteFailoverTestCase#testStatefulFailover}}
> Failing RemoteFailoverTestCase#testStatefulFailover when transaction run under JTS
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6160
> URL: https://issues.jboss.org/browse/WFLY-6160
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Reporter: Ondřej Chaloupka
> Assignee: Paul Ferraro
>
> I can see failing test {{RemoteFailoverTestCase#testStatefulFailover}} when transactions are set to run under JTS. I'm not sure if this is a trouble of clustering component or only a testsuite issue.
> This could be connected with JBEAP-1954.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months