November 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5984) Use Message.setFlag(short) to avoid creating a temporary array

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5984?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5984: ------------------------------- Status: Open (was: New) > Use Message.setFlag(short) to avoid creating a temporary array > -------------------------------------------------------------- > > Key: ISPN-5984 > URL: https://issues.jboss.org/browse/ISPN-5984 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Labels: performance > Fix For: 8.1.0.Beta2 > > > {{Message.setFlag(Message.Flag...)}} creates a temporary array on each invocation, and {{Message.setFlag(short)}} avoids it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5984) Use Message.setFlag(short) to avoid creating a temporary array

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5984?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5984: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3844 > Use Message.setFlag(short) to avoid creating a temporary array > -------------------------------------------------------------- > > Key: ISPN-5984 > URL: https://issues.jboss.org/browse/ISPN-5984 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Labels: performance > Fix For: 8.1.0.Beta2 > > > {{Message.setFlag(Message.Flag...)}} creates a temporary array on each invocation, and {{Message.setFlag(short)}} avoids it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5984) Use Message.setFlag(short) to avoid creating a temporary array

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5984: ---------------------------------- Summary: Use Message.setFlag(short) to avoid creating a temporary array Key: ISPN-5984 URL: https://issues.jboss.org/browse/ISPN-5984 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 8.1.0.Beta1 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Minor Fix For: 8.1.0.Beta2 {{Message.setFlag(Message.Flag...)}} creates a temporary array on each invocation, and {{Message.setFlag(short)}} avoids it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

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

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/ISPN-5983?page=com.atlassian.jira.plugin.... ] Ladislav Thon commented on ISPN-5983: ------------------------------------- Another option would be to do what WildFly is doing: port unification. That way, you wouldn't have to invent another port number. Downsides are probably obvious. > 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 > Assignee: 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)

10 years, 4 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5962: ------------------------------- Attachment: CompletableFutureBenchmarks.java I wrote a JMH benchmark to measure the difference between {{CompletableFuture.get()}}, {{CompletableFuture.get(timeout, unit)}}, and {{CountDownLatch.await()}}. The test appears to show a significant difference between all 3 when the CPU is saturated, with {{CompletableFuture.get()}} being the slowest. {noformat} Benchmark Mode Cnt Score Error Units CompletableFutureBenchmarks.completableFutureGetBusy thrpt 20 157501.654 ± 8227.728 ops/s CompletableFutureBenchmarks.completableFutureGetSleeping thrpt 20 6337.177 ± 37.172 ops/s CompletableFutureBenchmarks.completableFutureTimedGetBusy thrpt 20 178088.683 ± 7661.149 ops/s CompletableFutureBenchmarks.completableFutureTimedGetSleeping thrpt 20 6331.961 ± 29.550 ops/s CompletableFutureBenchmarks.countDownLatchAwaitBusy thrpt 20 194923.024 ± 7048.457 ops/s CompletableFutureBenchmarks.countDownLatchAwaitSleeping thrpt 20 6326.857 ± 28.239 ops/s {noformat} However, the difference between the two {{CompletableFuture}} methods disappears completely in some runs... {noformat} Benchmark Mode Cnt Score Error Units CompletableFutureBenchmarks.completableFutureGetBusy thrpt 20 173977.615 ± 7435.750 ops/s CompletableFutureBenchmarks.completableFutureGetSleeping thrpt 20 6340.609 ± 21.529 ops/s CompletableFutureBenchmarks.completableFutureTimedGetBusy thrpt 20 172650.973 ± 6382.962 ops/s CompletableFutureBenchmarks.completableFutureTimedGetSleeping thrpt 20 6314.509 ± 30.036 ops/s {noformat} > 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 > Attachments: CompletableFutureBenchmarks.java > > > 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)

10 years, 4 months

1
0
0 / 0

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

by Jiří Holuša (JIRA)

[ https://issues.jboss.org/browse/ISPN-5983?page=com.atlassian.jira.plugin.... ] Jiří Holuša commented on ISPN-5983: ----------------------------------- [~NadirX] I sent a pull request with documentation update with the second option, however, I don't know if this is the preferred option, WDYT? > 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 > Assignee: 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)

10 years, 4 months

1
0
0 / 0

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

by Jiří Holuša (JIRA)

[ https://issues.jboss.org/browse/ISPN-5983?page=com.atlassian.jira.plugin.... ] Jiří Holuša updated ISPN-5983: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/3843 > 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 > Assignee: 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)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5879) XSite client failover - ensure TcpTransportFactory.trySwitchCluster thread safety

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5879?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5879: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3842 > XSite client failover - ensure TcpTransportFactory.trySwitchCluster thread safety > --------------------------------------------------------------------------------- > > Key: ISPN-5879 > URL: https://issues.jboss.org/browse/ISPN-5879 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Remote Protocols > Reporter: Matej Čimbora > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 8.1.0.Beta2 > > > When reusing a HotRod client with several threads, site can be accidentally switched multiple times by threads invoking TcpTransportFactory.trySwitchCluster. This occurs when the threads attain 'maxRetries' limit at the same time, each of them being able to invoke TcpTransportFactory..updateServers with different 'clusterAddresses' parameter. This can lead to unpredictable result (e.g. switching back to failed cluster, while the other one (backup) is up and running). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3642) make isPre() an annotation property of the cache event

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3642?page=com.atlassian.jira.plugin.... ] William Burns closed ISPN-3642. ------------------------------- Resolution: Duplicate Issue Fixed via ISPN-5435 > make isPre() an annotation property of the cache event > ------------------------------------------------------ > > Key: ISPN-3642 > URL: https://issues.jboss.org/browse/ISPN-3642 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Listeners > Reporter: Mircea Markus > > the users should be able to configure cache event listeners like this: > {code:java} > @CacheEntryCreated(pre=true, post=false) > public void entryCreated(CacheEntryEvent e) { > //e.isPre() is no longer needed here > } > {code} > Discussed on the mailing list: http://infinispan.markmail.org/search/#query:+page:1+mid:y6enpffq3s4vb7fs... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

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

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/ISPN-5983?page=com.atlassian.jira.plugin.... ] Ladislav Thon commented on ISPN-5983: ------------------------------------- Just noting that with the first solution (adding the Undertow subsystem), a new socket binding would have to be created as well (in the code above, it would be called {{http}}). > 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 > Assignee: 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)

10 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2015