On Sat, Jun 4, 2011 at 4:13 PM, Senaka Fernando <[email protected]> wrote:
> Hi all, > > Just a thought. > > On Sat, Jun 4, 2011 at 3:10 PM, Tharindu Mathew <[email protected]> wrote: > >> >> >> On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez <[email protected]> wrote: >> >>> Sanjiva, Shankar & I had a discussion yesterday, and it seems that having >>> the event feature in most components is just overkill. Also, in Stratos, >>> QPid causes the server to go out of memory when we do load testing because >>> BAM tries to publish events, this will make all our services unstable hence >>> one of the most critical L1s. Sanjiva mentioned that Hiranya had developed a >>> bit of lightweight code for publishing these BAM events, and we could use >>> that. Apart from BAM, only deployment synchronizer uses this feature in the >>> case of the services such as AS, ESB etc right? >>> >>> G-Reg, DSS also use event components. IIRC, DSS for internal pub-sub and >> G-Reg for resource subscriptions. >> > > We had a stable in-memory WS-Eventing pub/sub implementation which was > re-factored into this Qpid-based version. Can't we have an in-memory version > (similar to what we had before), and use it in place of Qpid? Since the API > changes wasn't so complicated, won't this be possible? > hi Senaka, If you want to use the old event implementation you can use that. I is up to you to decide. But if you want to use an inmemory registry based system (as in old event implementaiton) only thing you need to do is to replace the delivery manager with this in event-broker.xml <delivaryManager name="delivaryManager" class="org.wso2.carbon.event.core.internal.delivary.inmemory.InMemoryDelivaryManagerFactory"> <minSpareThreads>25</minSpareThreads> <maxThreads>150</maxThreads> <maxQueuedRequests>100</maxQueuedRequests> <keepAliveTime>1000</keepAliveTime> <!--<matchingManager name="matchingManager"--> <!--class="org.wso2.carbon.event.core.internal.delivary.inmemory.InMemoryMatchingManagerFactory"/>--> <matchingManager name="matchingManager" class="org.wso2.carbon.event.core.internal.delivary.registry.RegistryMatchingManagerFactory"> <subscriptionStoragePath>event</subscriptionStoragePath> </matchingManager> </delivaryManager> But this is not properly tested since we do testing only with Qpid based delivery manager and does not support hierachical subscriptions. The problem with the old event implementation was the problem you had mentioned here. If we want to have a jms based event model then whole event broker implementation has to re wrote. This was the problem both Srinath and me talked when we were asked to merge it with a jms based implemenation and hence this new design. As you can see with the new model if some one want to publish event registry notifications to jms based one (suppose we by default shift registry based one) still it is a simple change of delivery manager. And we can have different jms based delivary managers if there are differences with those brokers. thanks, Amila. > > Thanks, > Senaka. > > >> We will lose some functionality of subscribing for topics and so forth, >> but with some testing we should be able to avoid leaks OOM errors. >> >> > >> The lightweight code was a tremendous improvement for high load scenarios. >> But for very high loads even this was failing. We had some improvements >> suggested and integrated(?), based on high and low watermarks plus a >> persistent queue as well. IIRC, these improvements were never properly load >> tested and verified. >> >> Also, are we doing this for this release? This would involve quite a bit >> of work, IMO. >> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>** >>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>> * >>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>> * >>> * >>> *Lean . Enterprise . Middleware* >>> >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> [email protected] >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> >> -- >> Regards, >> >> Tharindu >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *Senaka Fernando* > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2 Inc.; http://wso2.com* > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 > Linked-In: http://linkedin.com/in/senakafernando > > *Lean . Enterprise . Middleware > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
