airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lahiru Gunathilake <glah...@gmail.com>
Subject Re: GFac Handlers
Date Tue, 11 Jun 2013 13:17:43 GMT
Hi Sanjaya,

Please see my inline comments. I am proposing a solution for your issue
which looks more efficient rather writing two handlers. You can set a this
PGETaskInstance in to Jobexecutioncontext(see the AbstractContext class)
and use it in your outHandler, you really don't have to create two
instances if u want to reuse it.
On Tue, Jun 11, 2013 at 8:22 AM, Sanjaya Medonsa <sanjayamrt@gmail.com>wrote:

> Hi,
>      As per current design of Handlers, there are two types of handlers.
>         1. IN Handlers
>         2. OUT Handlers
>
> Basically IN handler does the pre processing and out handler does the post
> processing. With Airavata OODT integration, I am planning to implement IN
> handler to perform file staging and out handler perform output ingesting
> into CAS. That means two handler instances to handle pre/post processing.
> In my scenario, this approach seems bit inefficient. Both IN/OUT handlers
> are based on OODT PGETaskInstance. Due to current handler architecture, I
> need to create two instance of PGETaskInstance (One for IN handler and one
> for OUT handler). I guess we could have avoid this situation by having just
> GFac handlers which could either be IN, OUT or IN/OUT. In my case, I
> actually need to implement IN/OUT handler. In high level, I am proposing
> the following approach.
>         1. At configuration level no differentiation on IN/OUT handlers
>
Even now there's no difference in IN/OUT Handlers, it becomes IN or OUT
based on how you configure, its same interface, you can use one handler as
IN in one configuration and OUT in another configuration or in the same
configuration.

>         2. Instead GFacHandler interface should contain two methods
> (preInvoke/postInvoke). Depending on the type of handler either pre/post
> method should be implemented.
>                PRE - preInvoke
>                POST - postInvoke
>                PRE/POST - Both preInvoke/postInvoke
>
IMHO, current approach is more cleaner one which handle loose coupling with
one task at a time. If we do everything in single handler we need to keep
these data during whole time of execution. Job execution time could be huge
and we will be keeping all the Handler configuration in memory during the
whole execution time. I am not sure what is PGETaskInstance and whether its
efficient to keep this loaded during the whole execution period, other than
loading on demand by configuration.

>         3. Either we could instantiate all the handlers initially and
> invoke all pre methods prior to task execution and invoke all post methods
> after task execution.

If this approach is bit inefficient, then we could
> introduce type into handlers (PRE/POST/PREPOST). Prior to task execution we
> could instantiate PRE/PREPOST and invoke pre execution method.After task
> execution we could instantiate POST handlers and  invoke postExceution
> method for both POST/PREPOST handlers.
>
> I guess Handler may not be the correct name here, we could name these
> handlers as task wrappers as it refers in OODT. Let me know your feedback.
>
> Cheers,
> Sanjaya
>



-- 
System Analyst Programmer
PTI Lab
Indiana University

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message