camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Tam (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAMEL-1159) Check the logic in Aggregator.isBatchCompleted()
Date Mon, 15 Dec 2008 15:29:05 GMT

    [ https://issues.apache.org/activemq/browse/CAMEL-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48182#action_48182
] 

William Tam commented on CAMEL-1159:
------------------------------------

Thanks Claus.   The outBatchSize for Aggregator can be set via fluent builder and spring per
wiki currently but that is not the problem thought.  (I'll check resequencer and splitter.
 splitter does not extend BatchProcessor, tho).  Also, it is orthogonal to the xxxConfig works.
 What I saw was:

* Aggregator.isBatchCompleted() does not take the outBatchSize into the account.  The method
returns true if aggregationCompletedPredicate and collection.size() > 0.  So, the incoming
exchanges are correctly batched and stored the queue but the "out collection" is not batched.

* The BatchProcessor.isBatchCompleted() method checks for outBatchSize first and then ignore
"in" batchSize if it is true.   So, it could drain the in queue prematurely (i.e. drain the
quene before batchSize is > num).  I think we should have two methods: isInBatchCompleted()
and isOutBatchCompleted().  If isInBatchCompleted(), then it should drain the exchanges from
in queue to out collection.  if isOutBatchCompleted(), then we should sent out the exchanges.

I attached the patch.   Let me know if I am missing something.  I still have fix up the spring
test.




> Check the logic in Aggregator.isBatchCompleted()
> ------------------------------------------------
>
>                 Key: CAMEL-1159
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1159
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-core
>            Reporter: William Tam
>            Assignee: William Tam
>             Fix For: 2.0.0
>
>
> Understand the logic of this method and also see if the protected method getCollection()
is really needed (or getCollectionSize() is suffice).  The reason being supporting the getCollection()
method may constraint the BatchProcessor class to implement less efficient algorithm.
> {code}
>     @Override
>     protected boolean isBatchCompleted(int index) {
>         if (aggregationCompletedPredicate != null) {
>             // TODO: (davsclaus) What is the point with this code? I think its wrong
>             if (getCollection().size() > 0) {
>                 return true;
>             }
>         }
>         return super.isBatchCompleted(index);
>     }
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message