November 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5983) Cannot connect via JMX to servers managed in domain mode

by Jiří Holuša (JIRA)

Jiří Holuša created ISPN-5983: --------------------------------- Summary: Cannot connect via JMX to servers managed in domain mode Key: ISPN-5983 URL: https://issues.jboss.org/browse/ISPN-5983 Project: Infinispan Issue Type: Bug Components: Documentation-Servers, Server Affects Versions: 8.1.0.Beta1 Reporter: Jiří Holuša I was trying to connect remotely to Infinispan servers run in domain mode. I was following instructions that worked for me with Wildfly 10 (e.g. at https://goldmann.pl/blog/2013/04/16/jmx-connections-to-jboss-as/ ), but that didn't work with Infinispan servers. There is no documentation about how to do this and since it's not working the WildFly way, I mark this issue as bug. After investigation, we (many thanks to [~lthon]) found out that it doesn't work with ISPN server, because WildFly uses http upgrade for this purpose via http-connector. The connector (by default commented in the domain.xml) requires undertow subsystem to work, however, ISPN server doesn't have it. There are two possible solutions: * add the undertow subsystem. The modules/ directory already has the jars, therefore it's only needed to add following to domain.xml and than you can connect to the server via JMX URL service:jmx:remote+http://localhost:8080. However, I wouldn't prefer this solution. {code} <subsystem xmlns="urn:jboss:domain:undertow:3.0"> <buffer-cache name="default"/> <server name="default-server"> <http-listener name="default" socket-binding="http"/> <host name="default-host" alias="localhost"/> </server> <servlet-container name="default"/> </subsystem> {code} * second solution is to create remoting endpoint just the way it was before in JBoss AS 7, therefore add following to the domain.xml and then connect via JMX URL: service:jmx:remote://localhost:4447. This solution should be preferred IMHO. {code} <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/> {code} {code} <socket-binding name="remoting" port="4447"/> {code} I will soon issue a PR with the solution number 2 and appropriate update of documentation. Of course, these options should be disabled by default, by I think it would be nice to have them commented in the domain.xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5978) Unused scripts in EAP bin directory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5978?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5978: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1198413|https://bugzilla.redhat.com/show_bug.cgi?id=1198413] from POST to MODIFIED > Unused scripts in EAP bin directory > ----------------------------------- > > Key: ISPN-5978 > URL: https://issues.jboss.org/browse/ISPN-5978 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Beta1 > Reporter: Vaclav Dedik > Assignee: Vaclav Dedik > Fix For: 8.1.0.Final > > > There are these unecessary scripts in the EAP bin directory: > appclient.sh > jboss-cli.sh > wsconsume.sh > wsprovide.sh > appclient.sh, wsconsume.sh and wsprovide.sh are already removed from upstream. jboss-cli.sh is still present. > See bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=1198413 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5962) Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5962: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3841 > Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage > --------------------------------------------------------------------- > > Key: ISPN-5962 > URL: https://issues.jboss.org/browse/ISPN-5962 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Pedro Ruivo > > The method {{org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(Collection<Address>, ReplicableCommand, RpcOptions)}} is implemented by blocking on a {{CompletableFuture}}, but this then stalls on {{java.util.concurrent.CompletableFuture.waitingGet(boolean)}} by spending a significant amount of CPU time by spinning. > When implementing RPC calls and having to wait for remote operations, spinning is probably not a good idea. Could we try implementing this in some way to hint towards a more pessimistic lock? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5962) Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin.... ] Pedro Ruivo reassigned ISPN-5962: --------------------------------- Assignee: Pedro Ruivo > Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage > --------------------------------------------------------------------- > > Key: ISPN-5962 > URL: https://issues.jboss.org/browse/ISPN-5962 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Pedro Ruivo > > The method {{org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(Collection<Address>, ReplicableCommand, RpcOptions)}} is implemented by blocking on a {{CompletableFuture}}, but this then stalls on {{java.util.concurrent.CompletableFuture.waitingGet(boolean)}} by spending a significant amount of CPU time by spinning. > When implementing RPC calls and having to wait for remote operations, spinning is probably not a good idea. Could we try implementing this in some way to hint towards a more pessimistic lock? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5962) Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5962: ------------------------------ Status: Open (was: New) > Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage > --------------------------------------------------------------------- > > Key: ISPN-5962 > URL: https://issues.jboss.org/browse/ISPN-5962 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Pedro Ruivo > > The method {{org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(Collection<Address>, ReplicableCommand, RpcOptions)}} is implemented by blocking on a {{CompletableFuture}}, but this then stalls on {{java.util.concurrent.CompletableFuture.waitingGet(boolean)}} by spending a significant amount of CPU time by spinning. > When implementing RPC calls and having to wait for remote operations, spinning is probably not a good idea. Could we try implementing this in some way to hint towards a more pessimistic lock? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5962) Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin.... ] Work on ISPN-5962 started by Pedro Ruivo. ----------------------------------------- > Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage > --------------------------------------------------------------------- > > Key: ISPN-5962 > URL: https://issues.jboss.org/browse/ISPN-5962 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Pedro Ruivo > > The method {{org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(Collection<Address>, ReplicableCommand, RpcOptions)}} is implemented by blocking on a {{CompletableFuture}}, but this then stalls on {{java.util.concurrent.CompletableFuture.waitingGet(boolean)}} by spending a significant amount of CPU time by spinning. > When implementing RPC calls and having to wait for remote operations, spinning is probably not a good idea. Could we try implementing this in some way to hint towards a more pessimistic lock? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5982) Custom audit logger is ignored in server mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5982?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5982: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1284846 Bugzilla Update: Perform > Custom audit logger is ignored in server mode > --------------------------------------------- > > Key: ISPN-5982 > URL: https://issues.jboss.org/browse/ISPN-5982 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > > When custom audit logger is configured for cache container in server mode (e.g. sniplet bellow), it's ignored and default logger is still used > {noformat} > <authorization audit-logger="org.infinispan.server.test.security.log.TestAuditLogger"> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5982) Custom audit logger is ignored in server mode

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-5982: ------------------------------------- Summary: Custom audit logger is ignored in server mode Key: ISPN-5982 URL: https://issues.jboss.org/browse/ISPN-5982 Project: Infinispan Issue Type: Bug Components: Server Reporter: Vojtech Juranek When custom audit logger is configured for cache container in server mode (e.g. sniplet bellow), it's ignored and default logger is still used {noformat} <authorization audit-logger="org.infinispan.server.test.security.log.TestAuditLogger"> {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5981) Compatibility mode: HotRod client sends request to wrong owner

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5981?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5981: ------------------------------ Priority: Major (was: Critical) > Compatibility mode: HotRod client sends request to wrong owner > -------------------------------------------------------------- > > Key: ISPN-5981 > URL: https://issues.jboss.org/browse/ISPN-5981 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.1.Final, 8.1.0.Beta1 > Reporter: Dan Berindei > Attachments: GetAllCompatDistTest.java > > > The HotRod client computes the hash on the serialized key, i.e. {{MurmurHash3.hash(obj2bytes(key))}}, but the server decides the entry location based on the unmarshalled key, i.e. {{MurmurHash3.hash(key.hashCode())}}. > I've modified {{GetAllCompatDistTest}} (attached) to test if there are any {{ClusteredGetCommand}}s being sent for {{RemoteCache.get(key)}} operations, and it finds quite a few: > {noformat} > java.lang.AssertionError: expected:<100> but was:<147> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.8.8.jar:?] > at org.infinispan.client.hotrod.GetAllCompatDistTest.testGetWithCompatibility(GetAllCompatDistTest.java:57) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5981) Compatibility mode: HotRod client sends request to wrong owner

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5981?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5981: ------------------------------ Priority: Critical (was: Major) > Compatibility mode: HotRod client sends request to wrong owner > -------------------------------------------------------------- > > Key: ISPN-5981 > URL: https://issues.jboss.org/browse/ISPN-5981 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.1.Final, 8.1.0.Beta1 > Reporter: Dan Berindei > Priority: Critical > Attachments: GetAllCompatDistTest.java > > > The HotRod client computes the hash on the serialized key, i.e. {{MurmurHash3.hash(obj2bytes(key))}}, but the server decides the entry location based on the unmarshalled key, i.e. {{MurmurHash3.hash(key.hashCode())}}. > I've modified {{GetAllCompatDistTest}} (attached) to test if there are any {{ClusteredGetCommand}}s being sent for {{RemoteCache.get(key)}} operations, and it finds quite a few: > {noformat} > java.lang.AssertionError: expected:<100> but was:<147> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.8.8.jar:?] > at org.infinispan.client.hotrod.GetAllCompatDistTest.testGetWithCompatibility(GetAllCompatDistTest.java:57) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2015