[JBoss JIRA] (JGRP-1722) Improve performance of ENCRYPT protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1722.
----------------------------
Resolution: Done
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
> Key: JGRP-1722
> URL: https://issues.jboss.org/browse/JGRP-1722
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4
> Reporter: Martin Gencur
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads.
> It would be great if we could improve the performance of ENCRYPT protocol.
--
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-1722) Improve performance of ENCRYPT protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1722:
--------------------------------
Somewhat disappointing, but it looks as if the perf of ENCRYPT is largely a function of the speed of encryption and decryption. Adding a cipher pool didn't really improve performance for regular messages, but should improve it for {{OOB | DONT_BUNDLE}} messages.
Parallelization (e.g. concurrent decryption of all messages of a message batch) didn't help, either. The reason is that introducing yet another thread pool probably cancelled out the gains made, through increased context switching. I'll revisit this when baselining JGroups on JDK 7 where a shared fork-join thread pool can be used.
Also, uisng the asynchronous invocation API of JGroups would help as the encryption of the response would not have to be done on the same thread as the request, speeding of processing of message batches.
I'm resolving this for now, but I'm having a chat with Tristan to see if we can use a faster cipher...
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
> Key: JGRP-1722
> URL: https://issues.jboss.org/browse/JGRP-1722
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4
> Reporter: Martin Gencur
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads.
> It would be great if we could improve the performance of ENCRYPT protocol.
--
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:
--------------------------------------
Git Pull Request: https://github.com/belaban/JGroups/pull/129
> 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 fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1802:
--------------------------------------
Summary: OverlappingUnicastMergeTest fails to receive all messages (was: OverlappingUnicastMergeTest)
> OverlappingUnicastMergeTest fails to receive all messages
> ---------------------------------------------------------
>
> 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-3085) updating non existing and adding existing misc content with override on
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-3085:
---------------------------------------
Summary: updating non existing and adding existing misc content with override on
Key: WFLY-3085
URL: https://issues.jboss.org/browse/WFLY-3085
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Patching
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Rolling back a patch applied with override on which had an instruction to add a misc content that had existed before will fail because the opposite rolling back action for ADD is assumed to be REMOVE while in this case it has to be MODIFY to rollback to the previous version of the misc content.
A similar scenario will fail for the file update task. I.e. rolling back a patch applied with override on which had an instruction to modify a non-existing misc content will fail.
--
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-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:
-----------------------------------
Oh, this is just a workaround... not the recommended approach. Thanks for working through this!
> 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 Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1802:
--------------------------------
I don't think FIFO delivery is broken: it has worked for a long time and we'd notice this in other tests. But you're right, if a receiver gets messages from multiple senders concurrently, perhaps the receiver ({{receive(Message)}}) screwed it up. This could be similar to NakackTest where the receiver used an unsync'ed array list, which caused some messages to get dropped...
> 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-3051) http-remoting-jmx connection failure connecting to Undertow subsystem instead of Undertow management
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3051:
----------------------------------------
Hi [~johnhpatton], this is not a documentation issue it is a bug, a pull request has now been sent to correct the codebase.
In the meantime this issue contains the workaround description for those still hitting this.
> 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