[JBoss JIRA] (WFLY-3051) http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
by John Patton (JIRA)
[ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.... ]
John Patton commented on WFLY-3051:
-----------------------------------
I tried the method outlined here, seems to work for me, also! Any chance this can get added to the documentation? It wasn't very obvious to configure. :)
Thanks for the help!
> http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3051
> URL: https://issues.jboss.org/browse/WFLY-3051
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX, Remoting
> Affects Versions: 8.0.0.Final
> Reporter: Rituraj Sinha
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector use-management-endpoint="false"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector use-management-endpoint="false"/>
> </subsystem>
> as per the jboss-as-jmx_1_3.xsd its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
> <xs:annotation>
> <xs:documentation>
> If true then this connector will use the management endpoint, otherwise it will use the
> remoting subsystem endpoint.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------
Looking at the example above, it seems that message #1 from C is lost even though the message delivery should be FIFO.
Could this be a problem with the receiver code being accessed by multiple threads at the same time? Or is this an example of FIFO delivery being broken?
> OverlappingUnicastMergeTest
> ---------------------------
>
> Key: JGRP-1802
> URL: https://issues.jboss.org/browse/JGRP-1802
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B:
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-3084) make statistics-enabled for pool and jdbc stats in DataSources model attribute
by Stefano Maestri (JIRA)
Stefano Maestri created WFLY-3084:
-------------------------------------
Summary: make statistics-enabled for pool and jdbc stats in DataSources model attribute
Key: WFLY-3084
URL: https://issues.jboss.org/browse/WFLY-3084
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: JCA
Reporter: Stefano Maestri
Assignee: Stefano Maestri
Fix For: 9.0.0.CR1
Pulling up this statsistics-enabled attributes to specific Model attributes fro DataSource will make them marshallable and so will permit to keep statististics-enabled configuration set after server reload
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1802:
--------------------------------------
Description:
OverlappingUnicastMergeTest does the following:
- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the injected view
OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
What we expect to see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=15
receiver C: ucasts=15
{noformat}
What we instead see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=11
ucasts for B:
B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C
{noformat}
The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C.
was:
OverlappingUnicastMergeTest does the following:
- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the injected view
OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
What we expect to see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=15
receiver C: ucasts=15
{noformat}
What we instead see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=11
ucasts for B:
B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B
A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C
{noformat}
For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C.
> OverlappingUnicastMergeTest
> ---------------------------
>
> Key: JGRP-1802
> URL: https://issues.jboss.org/browse/JGRP-1802
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B:
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1802:
--------------------------------------
Description:
OverlappingUnicastMergeTest does the following:
- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the injected view
OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
What we expect to see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=15
receiver C: ucasts=15
{noformat}
What we instead see is:
{noformat}
receiver A: ucasts=15
receiver B: ucasts=11
ucasts for B:
B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B
A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C
{noformat}
For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C.
was:
OverlappingUnicastMergeTest does the following:
- set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
- the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
- inject some new view into the channels which represents a view configuration which should be recovered from
- send messages to the channels and check that the messages are received, despite the injected view
OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 through #3 from channel C.
> OverlappingUnicastMergeTest
> ---------------------------
>
> Key: JGRP-1802
> URL: https://issues.jboss.org/browse/JGRP-1802
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B:
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B
> A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C
> {noformat}
> For example, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1799 at 3/7/14 7:53 AM:
-------------------------------------------------------------------
Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.
For example, on Windows 2008:
{noformat}
------------- testLargeReturnValue -----------
testing with 10000 bytes
test took: 34 ms
rsps:
10000 bytes from A
10000 bytes from B
10000 bytes from C
testing with 20000 bytes
test took: 33 ms
rsps:
20000 bytes from A
20000 bytes from B
20000 bytes from C
testing with 40000 bytes
test took: 35 ms
rsps:
40000 bytes from A
40000 bytes from B
40000 bytes from C
testing with 80000 bytes
test took: 880 ms
rsps:
80000 bytes from A
80000 bytes from B
80000 bytes from C
testing with 100000 bytes
test took: 3574 ms
rsps:
100000 bytes from A
100000 bytes from B
100000 bytes from C
testing with 200000 bytes
test took: 5448 ms
rsps:
200000 bytes from A
200000 bytes from B
200000 bytes from C
testing with 400000 bytes
test took: 9975 ms
rsps:
400000 bytes from A
400000 bytes from B
400000 bytes from C
testing with 800000 bytes
test took: 18045 ms
rsps:
800000 bytes from A
800000 bytes from B
800000 bytes from C
testing with 1000000 bytes
test took: 22037 ms
rsps:
1000000 bytes from A
1000000 bytes from B
1000000 bytes from C
testing with 2000000 bytes
test took: 30074 ms
rsps:
{noformat}
There may also be GC activity in play here.
was (Author: rachmato):
Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.
For example, on Windows 2008:
{noformat}
------------- testLargeReturnValue -----------
testing with 10000 bytes
test took: 34 ms
rsps:
10000 bytes from A
10000 bytes from B
10000 bytes from C
testing with 20000 bytes
test took: 33 ms
rsps:
20000 bytes from A
20000 bytes from B
20000 bytes from C
testing with 40000 bytes
test took: 35 ms
rsps:
40000 bytes from A
40000 bytes from B
40000 bytes from C
testing with 80000 bytes
test took: 880 ms
rsps:
80000 bytes from A
80000 bytes from B
80000 bytes from C
testing with 100000 bytes
test took: 3574 ms
rsps:
100000 bytes from A
100000 bytes from B
100000 bytes from C
testing with 200000 bytes
test took: 5448 ms
rsps:
200000 bytes from A
200000 bytes from B
200000 bytes from C
testing with 400000 bytes
test took: 9975 ms
rsps:
400000 bytes from A
400000 bytes from B
400000 bytes from C
testing with 800000 bytes
test took: 18045 ms
rsps:
800000 bytes from A
800000 bytes from B
800000 bytes from C
testing with 1000000 bytes
test took: 22037 ms
rsps:
1000000 bytes from A
1000000 bytes from B
1000000 bytes from C
testing with 2000000 bytes
test took: 30074 ms
rsps:
{noformat}
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1799 at 3/7/14 7:52 AM:
-------------------------------------------------------------------
Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.
For example, on Windows 2008:
{noformat}
------------- testLargeReturnValue -----------
testing with 10000 bytes
test took: 34 ms
rsps:
10000 bytes from A
10000 bytes from B
10000 bytes from C
testing with 20000 bytes
test took: 33 ms
rsps:
20000 bytes from A
20000 bytes from B
20000 bytes from C
testing with 40000 bytes
test took: 35 ms
rsps:
40000 bytes from A
40000 bytes from B
40000 bytes from C
testing with 80000 bytes
test took: 880 ms
rsps:
80000 bytes from A
80000 bytes from B
80000 bytes from C
testing with 100000 bytes
test took: 3574 ms
rsps:
100000 bytes from A
100000 bytes from B
100000 bytes from C
testing with 200000 bytes
test took: 5448 ms
rsps:
200000 bytes from A
200000 bytes from B
200000 bytes from C
testing with 400000 bytes
test took: 9975 ms
rsps:
400000 bytes from A
400000 bytes from B
400000 bytes from C
testing with 800000 bytes
test took: 18045 ms
rsps:
800000 bytes from A
800000 bytes from B
800000 bytes from C
testing with 1000000 bytes
test took: 22037 ms
rsps:
1000000 bytes from A
1000000 bytes from B
1000000 bytes from C
testing with 2000000 bytes
test took: 30074 ms
rsps:
{noformat}
was (Author: rachmato):
Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1799:
-------------------------------------------
Bela, there are still failures of this test at the highest size which take more than 30 seconds on slow machines.
Can we increase this timeout to 60 seconds, from 30 seconds, as it is another case of a test which should eventually return a value and not within any specific time bound.
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months