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

[Thomas Menzel <tmenzel@xxxxxxx>]

FYI

I updated the wiki page and added expanded the requirement "compound management, splitting of records".


Kind regards
Thomas Menzel @ brox IT-Solutions GmbH


> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Thomas Menzel
> Sent: Mittwoch, 7. Oktober 2009 09:49
> To: Smila project developer mailing list
> Subject: RE: [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.
> 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
> _______________________________________________
> 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/07/09 05:18:00