Hi Surajit and Nina,

On Tue, 2010-11-30 at 07:47 +0200, Nina Jeliazkova wrote:

> Hi ,
> 
> Surajit's suggestion is better IMHO.
> 
> AA could be applied not only upfront, but anywhere else within the task
> (think superservice accessing multiple resources, or just a model service
> writing results to remote dataset service, both protected by AA). Reporting
> failed AA might be a just regular error report.


...and in particular an error report included in the Task
representation; then that's OK for me about choosing one status code
(Rejected) over the other (Error). The number of queues is something
internal and is not revealed to the client, but we think this structure
might lead to better performance. BTW, we just kicked off a new project,
JAQPOT [pronounced Jack Pot] (Just Another Qsar Project under OpenTox)
and we'll try some performance enhancements. 

Pantelis


P.S. Jaqpot source code available at
https://github.com/alphaville/jaqpot (Nothing to see yet)

> 
> Regards,
> Nina
> 
> On 30 November 2010 06:30, surajit ray <mr.surajit.ray at gmail.com> wrote:
> 
> > Hi,
> >
> > We could have just one queue ....and when a task with pending approval
> > comes up for execution - the AA is sought and if failed the task is
> > cancelled with an error report. How about that ?
> >
> > Regards
> > Surajit
> >
> >
> > On 30 November 2010 01:43, chung <chvng at mail.ntua.gr> wrote:
> > > Dear All,
> > >  An idea about better handling of tasks and AA:
> > > Now before a task is created, the service asks the SSO service for
> > > permission. If A or A fails, an error report is returned to the user.
> > > Our idea is about creating and returning a task to the user with status
> > > 'PendingAA' (new) prior to AA. At this point the task is put in a queue
> > > where it is not yet executed but is pending for approval by the SSO
> > > service. This way, the client acquires the task faster and the
> > > connection is released immediately. In case of AA failure, an error
> > > report can be included in the task representation (the task will have
> > > status 'Rejected' - and not 'Error' which implies that the service was
> > > submitted for execution). So, the idea is about having two queues of
> > > different size: A queue for tasks pending for approval and one for task
> > > execution. Furthermore, the client has a better insight of what's going
> > > on monitoring the task's status. What do you think?
> > >
> > > Best regards,
> > > Pantelis
> > >
> > > P.S. Requests that are not expected to return a task, such as all GET
> > > requests, will inevitably have the client waiting for tokenid
> > > verification and no queue is needed.
> > > _______________________________________________
> > > Development mailing list
> > > Development at opentox.org
> > > http://www.opentox.org/mailman/listinfo/development
> > >
> > _______________________________________________
> > Development mailing list
> > Development at opentox.org
> > http://www.opentox.org/mailman/listinfo/development
> >
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>