[
https://issues.apache.org/jira/browse/OMID-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412680#comment-15412680
]
ASF GitHub Bot commented on OMID-50:
------------------------------------
Github user francisco-perez-sorrosal commented on a diff in the pull request:
https://github.com/apache/incubator-omid/pull/3#discussion_r73978116
--- Diff:
tso-server/src/test/java/org/apache/omid/tso/TestPersistenceProcessor.java ---
@@ -145,7 +145,7 @@ public void
testCommitPersistenceWithSingleCommitTableWriter() throws Exception
ObjectPool<Batch> batchPool = spy(new
BatchPoolModule(tsoConfig).getBatchPool());
- ReplyProcessor replyProcessor = new ReplyProcessorImpl(metrics,
panicker, batchPool);
+ ReplyProcessor replyProcessor = new ReplyProcessorImpl(tsoConfig,
metrics, panicker, batchPool);
--- End diff --
According to the changes above regarding to WaitStrategy injections, the
*ProcessorImpl clases in all the tests should create the objects of the
previous WaitStrategy in each case. This is the matching:
PersistenceProcessorImpl - BlockingWaitStrategy
ReplyProcessorImpl - BlockingWaitStrategy
RetryProcessorImpl - YieldingWaitStrategy
e.g. here should be:
```java
ReplyProcessor replyProcessor = new ReplyProcessorImpl(new
BlockingWaitStrategy(), metrics, panicker, batchPool);
```
The same applies to the other *ProcessorImpl instantiations below.
> Provide an option to reduce tso-server CPU usage
> ------------------------------------------------
>
> Key: OMID-50
> URL: https://issues.apache.org/jira/browse/OMID-50
> Project: Apache Omid
> Issue Type: Improvement
> Reporter: Daniel Dai
> Assignee: Daniel Dai
> Fix For: 0.8.2.10
>
> Attachments: OMID-50-1.patch
>
>
> Currently tso-server use 300% cpu even at idle time. The reason for this 300%
> cpu usage is due to the BusyWaitStrategy used in disruptor. While this is
> good for throughput, it wastes resources in many use cases. In this ticket, I
> provide a config to use a different wait strategy and reduce the cpu usage
> with the option on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)