[JBoss JIRA] (ISPN-5982) Custom audit logger is ignored in server mode
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5982?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5982:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.1.0.CR1
8.1.0.Final
Resolution: Done
> 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
> Assignee: Vojtech Juranek
> Fix For: 8.1.0.CR1, 8.1.0.Final
>
>
> 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, 5 months
[JBoss JIRA] (ISPN-5962) Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-5962:
---------------------------------------
BTW we've observed a 10% CPU usage drop, with slightly improved throughput too, so I thought this was a pretty clear picture and an easy decision.
> 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)
8 years, 5 months
[JBoss JIRA] (ISPN-5962) Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-5962:
---------------------------------------
Thanks Dan! But now you'll have to explain why you have those figures ;-) Maybe share the benchmark code?
My opinion is that avoiding the spinning is important in the Infinispan case as we're in a special condition of:
- being blocked on network IO
- having way too many threads which could make good use of the CPU which is being hold hostage by this code.
If you're just "saturating CPU" in a micro benchmark, that's not good enough to put you in the same conditions, as the threads busy spinning would just keep other threads to pointlessly be spinning as well.. so improve your results artificially.
> 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)
8 years, 5 months