+1 for the changes. We can take advantage of such framework to handle provider level decencies also and avoid any classpath issues. Are you planning to have handlers/providers as service which orchestrator can route the request to? This approach can be used to distribute the load also going forward.
Thanks Raminder On Apr 30, 2014, at 12:09 PM, Lahiru Gunathilake <[email protected]> wrote: > Hi All, > > As we have discussed me and Nipun finished 80% of separation gfac-core from > its own implementation and split those implementation in to different > modules. I am planning to add following features to gfac-core and move the > monitoring implementation out of gfac-core which will use the following > framework features. > > 1. Developers can configure daemon type handlers which are not specific for > each request but common to the jvm. These daemon type handlers will start > during gfac initializing and shutdown during gfac shutdown. All the > handlers/provider which get execute for each request can access the daemon > handlers and can give some work for them. (basically jobexecution context has > access to the configured daemon handlers). > > 2. Developers can configure request specific handlers to run in separate > thread. Currently we are running all the handlers for a given request in a > single thread but if you implement ThreadedHandler and configure it in the > execution chain rather configuring as a global daemon handler it will get > execute in a separate thread. But this is for each execution request which > matches your handler chain. > > I am planning to use above feature of the gfac framework and implement a > reliable monitoring for hpc resources we support. So there will be another > gfac implementation module like gfac-hpc-monitor and it will not be coupled > with gfac-core. > > Thanks > Lahiru > > -- > System Analyst Programmer > PTI Lab > Indiana University
