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

[Thomas Menzel <tmenzel@xxxxxxx>]

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.

> while I
> want to define the problem and the solution requirements first.

Well, I thought I exactly did that. Namely in sections "core problem" and "indexing requirements", or not?
past mails have also been a discussion how and if certain conditions exist that violate requirements.

So, if you think any of the requirements listed and explained so far, doesn't exist or is wrong, then say so.
But if it does, then we need to find a solution to meet it. 

Agreed, not all will be equally important and in some scenarios the requirement is already met as the condition doesn't arise in the application, eg. we just have a project where we use agents and they said that they wont have changes in close succession. Fine, that is great. but only in that project. There might be another where that is not the case.

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.

A 2nd step then is to see if the effort to implementation the solution (or maybe there is not just one but several to combine) is worth the requirement it meets and here, and *only* here, is the point where the likelihood of the occurrence comes into the decision process.


> My major points are:
>  1. This problem does currently exist.
+1

>  2. The occurrence is quite low - in real word use cases.
+1
... which is also the reason we didn't cover it yet

>  3. In order to be highly scalable _we must take care_ that this
> problem
> does not occur

+/-1 

+1 for the last part of the sentence, but it is not a consequence of wanting to be scalable, or what do you mean by this?
solving this matter (execution of operations in proper order or their consolidation) doesn't bring us any perf. gain per say. More likely is, that we lose performance by solving the issue.

If I may rephrase this point, as I would see it:

	In order to provide a correctly working solution in all circumstances 
	> _we must take care_ that this
	> problem
	> does not occur


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


So long and good night.

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 17:04
> To: smila-dev@xxxxxxxxxxx
> Subject: AW: [smila-dev] RE: FYI :: new feature :: Message Resequencer
> 
> Hi Thomas,
> 
> > Before I answer all your questions (and I feel rather silly about
> that) I think
> > the main diff. between our two approaches are, that you are looking
> for a solution
> > that works 90% of the times while I have been thinking about a
> solution that works
> > 100% of the times (at least I hope so) and hence the elaborate wiki
> page.
> I have the impression, that you've missed my point:
> You are constantly debating the approach to solve the problem, while I
> want to define the problem and the solution requirements first.
> 
> So to avoid further misunderstanding I'll try to be very brief:
> 
> The problem (that you're trying to solve with resequencer) can be
> defined as: "The execution order of operations on _one_ particular
> record _does_ matter and _must be_ obeyed."
> 
> My major points are:
>  1. This problem does currently exist.
>  2. The occurrence is quite low - in real word use cases.
>  3. In order to be highly scalable _we must take care_ that this
> problem
> does not occur!
> 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?
> 
> BTW: I would be very happy if other team members would join this IMO
> important discussion. Guys, please participate!
> 
> Regards
> 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