Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [smila-dev] RE: FYI :: new feature :: Message Resequencer

Hi,

> > scalability
> Your argument against this point gives me the impression that you
might not have
> understood my proposal fully.
Well, that might be true. 
But I am not solely to blame on that since:
	- Your proposal is everything else but trivial. Actually you
proposed 2 things...
	- The description is 8k plain text long. 
	- You introduced almost a dozen of new terms and
abbreviations...

Nevertheless, I've just read it again (several times :-) and still see
some serious flaws in it:
1. Your approach is not general. You concentrate on something you call
"processing targets" and completely neglect the price of preprocessing.
Please forget the processing target and assume, that each pipelet in the
Pipeline fetches the record from the blackboard and stores it either in
blackboard or in some own store (e.g. index file). Also assume that
every Pipelet takes some significant time to perform. Therefore we must
prevent the unnecessary calls of _any_ pipelet.
2. Both "full" and "smart" resequencer share the same problem: In a
cluster environment you will have at least one resequencer instance per
node. How will those instances share their ID-SN-Maps in a performant
way?


> > I'm confident that this is possible. The way to do this is by
buffering
> > document operations.
> > Can we discuss buffering now?
> 
> Do it, and show that all requirements are met.
> I suggest you do this in the buffer section explaining after the
manner I have
> described the SRS, that is
> - working principle:
> - show how each requirements is or may be met. Plz also include all
the items I
> mentioned thus far.
Done. Please take a look at " Idea 1 - Connectivity
Consolidation/Resequencer Buffer" section of
http://wiki.eclipse.org/SMILA/Specifications/ProcessingMessageResequence
r 

Regards
Igor


Back to the top