RE: [smila-dev] RE: FYI :: new feature :: Message Resequencer

[Thomas Menzel <tmenzel@xxxxxxx>]

Hi,


> scalability
Your argument against this point gives me the impression that you might not have understood my proposal fully.
With that model we can have thousands of consumers processing the input in parallel. The bottleneck is where it goes into the index. and that is a bottleneck anyway b/c even in a clustered solution you only can have one write master and only its input is resequenced. Its just an additional processing service call.

> 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.

Kind regards
Thomas Menzel @ brox IT-Solutions GmbH


> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Igor.Novakovic@xxxxxxxxxxx
> Sent: Dienstag, 6. Oktober 2009 23:55
> To: smila-dev@xxxxxxxxxxx
> Subject: AW: [smila-dev] RE: FYI :: new feature :: Message Resequencer
> 
> Hi,
> 
> > > I have the impression, that you've missed my point:
> > > You are constantly debating the approach to solve the problem,
> >
> > I'm suggesting a solution that meets (all) the requirements. And IMOH
> I'm arguing
> > how it does that and how others do or don't.
> Don't you see? You talk again about the solution ;-)
> 
> Seriously:
> The most important requirement is the scalability.
> Does your solution scale?
> What I mean with scaling is, can we have hundreds and thousands of
> queue
> consumers that operate _fully_ independent (not to wait each other just
> to keep the order of operations)?
> 
> To be honest, I do not see how you solution can fulfill this
> requirement.
> 
> My point is (as stated many times already):
> Do not try to solve this problem if we know that we can prevent it.
> Let's work on problem prevention!
> 
> > As I wrote in my last mail: my setout is to look for a solution that
> meets _all_
> > requirements _independent_ of their likely hood to happen.
> Like Daniel and I earlier stated: Your solution does not scale. The
> most
> important requirement (which is scalability) is not met.
> 
> 
> > > Therefore I would define the _real_ problem as: "How to make sure
> that
> > > the execution order of operations on _one_ particular record _does
> not_
> > > matter."
> > > Can we agree on this?
> >
> > If that is possible, to transform the problem into that: great! Let's
> hear it.
> I'm confident that this is possible. The way to do this is by buffering
> document operations.
> Can we discuss buffering now?
> 
> Cheers
> Igor
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.420 / Virus Database: 270.14.4/2417 - Release Date:
> 10/06/09 06:50:00