On Thu, Jan 9, 2014 at 5:10 PM, Paul Fremantle <[email protected]> wrote:
> We have an agreed model and architecture for doing tasks across a > cluster... it is the Task Server which issues HTTP requests. These go > through the ELB and then one of our servers E.g. ESB, AS, DSS, etc does > some work. Unless there is a problem with this model we shouldn't be > inventing another model. +1, also we also do have the ntask component, which is used in the platform for many task scheduling functionality (DSS, BAM, GREG etc..). And this component is already based on Hazelcast for coordination. And as Paul explained, Task Server (the same internal tasks can be automatically offloaded to this as well), can be used to do remote tasks, based on HTTP requests. Cheers, Anjana. > I'm +1 on a registry mediator. > > Paul > > > On Thursday, 2 January 2014, Samisa Abeysinghe wrote: > >> >> >> On Thu, Jan 2, 2014 at 5:10 PM, Kasun Indrasiri <[email protected]> wrote: >> >>> Hi, >>> >>> We may have couple of use case to add registry resources from a >>> mediation flow (similar to a DBReport behavior). So we might need a similar >>> mediator which can add content in to the registry. This should use the >>> org.apache.synapse.registry.Registry api and we should not write any >>> carbon specific code in it. >>> >> >> So does this mean that this new mediator is just a wrapper for the >> Registry API? >> >> >>> >>> But this is not a good approach to achieve coordinations between tasks. >>> >> >> Why not? Is it due to possible race conditions? >> >> >> >>> We are planning to have a new scheduled task implementation on top of >>> Hazelcast which can cater all such requirements. >>> >>> >>> On Thu, Jan 2, 2014 at 4:05 PM, Amila Maha Arachchi <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> At the moment, ESB can only get the registry properties. But it seems >>>> useful to put and update properties to the registry too. >>>> >>>> This can be used when coordinating a scheduled task between multiple >>>> ESB nodes. If we have multiple ESB nodes and theres a scheduled task, we >>>> dont have a way to control them running in a single node. We have the >>>> pinned server concept. But it does not have a failover mechanism. So, if we >>>> can use a flag in the registry and if ESB can update it when starting the >>>> task (similar to a lock we use in programming), it can be used to >>>> coordinate. >>>> >>>> For the above requirement, ESB needs to support putting and updating >>>> properties to the registry. I think it wont be difficult since get is >>>> already there. >>>> >>>> Regards, >>>> AmilaM. >>>> >>>> -- >>>> *Amila Maharachchi* >>>> Senior Technical Lead >>>> WSO2, Inc.; http://wso2.com >>>> >>>> Blog: http://maharachchi.blogspot.com >>>> Mobile: +94719371446 >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > > -- > Paul Fremantle > CTO and Co-Founder, WSO2 > OASIS WS-RX TC Co-chair, Apache Member > > UK: +44 207 096 0336 > US: +1 646 595 7614 > > blog: http://pzf.fremantle.org > twitter.com/pzfreo > [email protected] > > wso2.com Lean Enterprise Middleware > > Disclaimer: This communication may contain privileged or other > confidential information and is intended exclusively for the addressee/s. > If you are not the intended recipient/s, or believe that you may have > received this communication in error, please reply to the sender indicating > that fact and delete the copy you received and in addition, you should not > print, copy, retransmit, disseminate, or otherwise use the information > contained in this communication. Internet communications cannot be > guaranteed to be timely, secure, error or virus-free. The sender does not > accept liability for any errors or omissions. > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Anjana Fernando* Technical Lead WSO2 Inc. | http://wso2.com lean . enterprise . middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
