Re: [Carbon-dev] Removing event feature from most products
On Tue, Jun 7, 2011 at 3:02 PM, Tharindu Mathew thari...@wso2.com wrote: For high load systems, we can always recommend to increase the event threshold. The practical approach is to define a maximum queue length for executor. If the system hit this limit system drop the messages effectively increasing the threshold automatically. If events are published within a time interval, that will work with stat module since there is no accumulation of memory. But if the events has to store in memory (for activity monitoring) then the amount of memory need will grow with increase of message rate. Again the only solution is to limit the size and drop if goes after some point. Therefore first, the data saving path of the BAM publishers should be optimized so that a rate at which it can work goes to the possible upper limit. After that there should be a proper mathematical model which make it operate at the highest point in a high load and drop messages after that without going to OOM. thanks, Amila. When bursts occur, the default value of 20, is definitely not enough. On Tue, Jun 7, 2011 at 2:47 PM, Amila Suriarachchi am...@wso2.com wrote: In a separate note the BAM publisher memory leak is not related to Qpid memory leak which we experience in long running. BAM publisher problem is mainly due to speed mismatching. i.e BAM publisher publish the messages to its internal thread pool queue in a much higher rate than it submit the message to the Qpid queue. This is becuase it take some time to publish the message to Qpid and it uses only one thread for that. (even with multiple threads it failing) In other words this OOM issue is caused by the tasks accumilated in the BAM thread pool. The only solution for this is to improve the performace of the path which saves the BAM messages to the database. Directly saving messages to the data base using jdbc from the BAM publisher it self is the fastest and hence can withhold for higher speeds. Anyway even that has an upper limit after which there will be an OOM error due to speed mismatch. thanks, Amila. On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. /sumedha On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.comwrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880| +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Thu, Jun 9, 2011 at 6:51 PM, Amila Suriarachchi am...@wso2.com wrote: On Tue, Jun 7, 2011 at 3:02 PM, Tharindu Mathew thari...@wso2.com wrote: For high load systems, we can always recommend to increase the event threshold. The practical approach is to define a maximum queue length for executor. If the system hit this limit system drop the messages effectively increasing the threshold automatically. If events are published within a time interval, that will work with stat module since there is no accumulation of memory. But if the events has to store in memory (for activity monitoring) then the amount of memory need will grow with increase of message rate. Again the only solution is to limit the size and drop if goes after some point. Therefore first, the data saving path of the BAM publishers should be optimized so that a rate at which it can work goes to the possible upper limit. After that there should be a proper mathematical model which make it operate at the highest point in a high load and drop messages after that without going to OOM. There is also a limitation of not being able to use a thread pool to dequeue from the queue. Since we look at the cumulative count, we need to preserve order, thus using a single thread to dequeue. This is a big hit IMO. This is something we can improve and fix at the BAM server side for a future release. To look at time stamp (sent by the publisher) and get the latest message when displaying on the dashboard, regardless of the order that it came in. This will allow us to use a pool. Lots of learning we can apply as we are writing the new BAM :) thanks, Amila. When bursts occur, the default value of 20, is definitely not enough. On Tue, Jun 7, 2011 at 2:47 PM, Amila Suriarachchi am...@wso2.comwrote: In a separate note the BAM publisher memory leak is not related to Qpid memory leak which we experience in long running. BAM publisher problem is mainly due to speed mismatching. i.e BAM publisher publish the messages to its internal thread pool queue in a much higher rate than it submit the message to the Qpid queue. This is becuase it take some time to publish the message to Qpid and it uses only one thread for that. (even with multiple threads it failing) In other words this OOM issue is caused by the tasks accumilated in the BAM thread pool. The only solution for this is to improve the performace of the path which saves the BAM messages to the database. Directly saving messages to the data base using jdbc from the BAM publisher it self is the fastest and hence can withhold for higher speeds. Anyway even that has an upper limit after which there will be an OOM error due to speed mismatch. thanks, Amila. On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. /sumedha On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.comwrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Thu, Jun 9, 2011 at 10:39 PM, Tharindu Mathew thari...@wso2.com wrote: On Thu, Jun 9, 2011 at 6:51 PM, Amila Suriarachchi am...@wso2.com wrote: On Tue, Jun 7, 2011 at 3:02 PM, Tharindu Mathew thari...@wso2.comwrote: For high load systems, we can always recommend to increase the event threshold. The practical approach is to define a maximum queue length for executor. If the system hit this limit system drop the messages effectively increasing the threshold automatically. If events are published within a time interval, that will work with stat module since there is no accumulation of memory. But if the events has to store in memory (for activity monitoring) then the amount of memory need will grow with increase of message rate. Again the only solution is to limit the size and drop if goes after some point. Therefore first, the data saving path of the BAM publishers should be optimized so that a rate at which it can work goes to the possible upper limit. After that there should be a proper mathematical model which make it operate at the highest point in a high load and drop messages after that without going to OOM. There is also a limitation of not being able to use a thread pool to dequeue from the queue. Since we look at the cumulative count, we need to preserve order, thus using a single thread to dequeue. This is a big hit IMO. This is something we can improve and fix at the BAM server side for a future release. To look at time stamp (sent by the publisher) and get the latest message when displaying on the dashboard, regardless of the order that it came in. This will allow us to use a pool. +1. In distributed computing there is a concept called logical clock for this kind of scenarios. you can keep some sequence number at the message generation point to preserve the order. thanks, Amila. Lots of learning we can apply as we are writing the new BAM :) thanks, Amila. When bursts occur, the default value of 20, is definitely not enough. On Tue, Jun 7, 2011 at 2:47 PM, Amila Suriarachchi am...@wso2.comwrote: In a separate note the BAM publisher memory leak is not related to Qpid memory leak which we experience in long running. BAM publisher problem is mainly due to speed mismatching. i.e BAM publisher publish the messages to its internal thread pool queue in a much higher rate than it submit the message to the Qpid queue. This is becuase it take some time to publish the message to Qpid and it uses only one thread for that. (even with multiple threads it failing) In other words this OOM issue is caused by the tasks accumilated in the BAM thread pool. The only solution for this is to improve the performace of the path which saves the BAM messages to the database. Directly saving messages to the data base using jdbc from the BAM publisher it self is the fastest and hence can withhold for higher speeds. Anyway even that has an upper limit after which there will be an OOM error due to speed mismatch. thanks, Amila. On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. /sumedha On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.comwrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.com wrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev
Re: [Carbon-dev] Removing event feature from most products
In a separate note the BAM publisher memory leak is not related to Qpid memory leak which we experience in long running. BAM publisher problem is mainly due to speed mismatching. i.e BAM publisher publish the messages to its internal thread pool queue in a much higher rate than it submit the message to the Qpid queue. This is becuase it take some time to publish the message to Qpid and it uses only one thread for that. (even with multiple threads it failing) In other words this OOM issue is caused by the tasks accumilated in the BAM thread pool. The only solution for this is to improve the performace of the path which saves the BAM messages to the database. Directly saving messages to the data base using jdbc from the BAM publisher it self is the fastest and hence can withhold for higher speeds. Anyway even that has an upper limit after which there will be an OOM error due to speed mismatch. thanks, Amila. On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.com wrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. /sumedha On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.comwrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
For high load systems, we can always recommend to increase the event threshold. When bursts occur, the default value of 20, is definitely not enough. On Tue, Jun 7, 2011 at 2:47 PM, Amila Suriarachchi am...@wso2.com wrote: In a separate note the BAM publisher memory leak is not related to Qpid memory leak which we experience in long running. BAM publisher problem is mainly due to speed mismatching. i.e BAM publisher publish the messages to its internal thread pool queue in a much higher rate than it submit the message to the Qpid queue. This is becuase it take some time to publish the message to Qpid and it uses only one thread for that. (even with multiple threads it failing) In other words this OOM issue is caused by the tasks accumilated in the BAM thread pool. The only solution for this is to improve the performace of the path which saves the BAM messages to the database. Directly saving messages to the data base using jdbc from the BAM publisher it self is the fastest and hence can withhold for higher speeds. Anyway even that has an upper limit after which there will be an OOM error due to speed mismatch. thanks, Amila. On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. /sumedha On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.comwrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880| +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Tue, Jun 7, 2011 at 3:02 PM, Tharindu Mathew thari...@wso2.com wrote: For high load systems, we can always recommend to increase the event threshold. When bursts occur, the default value of 20, is definitely not enough. The other option is to BAM publisher publish data from some time interval, rather than for number of requests. (Increasing the threshold we effectively increase the time). Here BAM publisher can polls the stat collector for given period of time and publish data. Then the BAM publisher speed is not depend on the service access rate. thanks, Amila. On Tue, Jun 7, 2011 at 2:47 PM, Amila Suriarachchi am...@wso2.com wrote: In a separate note the BAM publisher memory leak is not related to Qpid memory leak which we experience in long running. BAM publisher problem is mainly due to speed mismatching. i.e BAM publisher publish the messages to its internal thread pool queue in a much higher rate than it submit the message to the Qpid queue. This is becuase it take some time to publish the message to Qpid and it uses only one thread for that. (even with multiple threads it failing) In other words this OOM issue is caused by the tasks accumilated in the BAM thread pool. The only solution for this is to improve the performace of the path which saves the BAM messages to the database. Directly saving messages to the data base using jdbc from the BAM publisher it self is the fastest and hence can withhold for higher speeds. Anyway even that has an upper limit after which there will be an OOM error due to speed mismatch. thanks, Amila. On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. /sumedha On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.comwrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880| +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. /sumedha On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.com wrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
Hi, On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.com wrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. The above bit of code runs on top of a simple queue + thread pool framework thus making the whole thing asynchronous. I also had implemented provision for plugging in a different approach for dealing with the objects stored in the queue. So for an example one could write a simple lightweight Axis2 client which picks these objects from the queue and sends to the BAM server through WS calls. Thanks, Hiranya Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.com wrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. One product can have only one broker. i.e if bam publisher in ESB wants to use the in memory one, then all the other components, GReg, Deployment synchronizer, publish mediator should use that. thanks, Amila. /sumedha On Mon, Jun 6, 2011 at 10:50 AM, Tharindu Mathew thari...@wso2.comwrote: On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.comwrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
Based on our discussion, I did a basic POC of removing event component and doing the changes to deploy the bam data publishers, and seems that we will have to change at least the publisher service endpoint address, and patch BAM. This is because if the event WS is already in the product (and it most probably will be since registry, deployment synchronizer needs it), and the name will clash if we use the same name for the BAM publisher WS. So if we use a different name, the service endpoint will change, thus, requiring us to change at least a line of code in BAM. On Mon, Jun 6, 2011 at 2:20 PM, Sanjiva Weerawarana sanj...@wso2.comwrote: Oneven Mon, Jun 6, 2011 at 2:04 PM, Amila Suriarachchi am...@wso2.comwrote: On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. One product can have only one broker. i.e if bam publisher in ESB wants to use the in memory one, then all the other components, GReg, Deployment synchronizer, publish mediator should use that. ARGH. This is NOT going to work guys. Can we please reconvene and rehash the discussion? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
Of course, we can make this endpoint configurable through the bam,xml. This might solve the problem. On Tue, Jun 7, 2011 at 1:50 AM, Tharindu Mathew thari...@wso2.com wrote: Based on our discussion, I did a basic POC of removing event component and doing the changes to deploy the bam data publishers, and seems that we will have to change at least the publisher service endpoint address, and patch BAM. This is because if the event WS is already in the product (and it most probably will be since registry, deployment synchronizer needs it), and the name will clash if we use the same name for the BAM publisher WS. So if we use a different name, the service endpoint will change, thus, requiring us to change at least a line of code in BAM. On Mon, Jun 6, 2011 at 2:20 PM, Sanjiva Weerawarana sanj...@wso2.comwrote: Oneven Mon, Jun 6, 2011 at 2:04 PM, Amila Suriarachchi am...@wso2.comwrote: On Mon, Jun 6, 2011 at 1:28 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This is the conclusion from the discussion happened little while ago. As Amila mentioned, we can switch to in-memory storage from Qpid. But this has not been fully test. We will test this set up (in-memory) using BAM then make the change permanent for 3.2.0. This way, each of the products will have a minimum impact from a code change perspective. One product can have only one broker. i.e if bam publisher in ESB wants to use the in memory one, then all the other components, GReg, Deployment synchronizer, publish mediator should use that. ARGH. This is NOT going to work guys. Can we please reconvene and rehash the discussion? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Sun, Jun 5, 2011 at 8:20 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: I'd like to come for this discussion too please. On Azeez's proposal- he's not suggesting removing the Qpid based event broker from products that have event publishing as a feature. Those are G-Reg, DSS and ESB AFAIK. Those products will continue to use the broker. However all products have the BAM publisher to push information out to the BAM server. The suggestion is to change so that ALL products (including the 3 listed above) use a different BAM publishing codebase and not use the event broker to publish BAM data. BAM publishing has NOTHING to do with eventing- all that's needed is for the publication to happen on a low priority threadpool and for the initial recording of information to be non-blocking to the max. Furthermore the server should NEVER be able to crash while trying to publish data to BAM. Ideally it should never lose any messages but if the choice is between having the publishing stuff grow to a point of threatening the health of the server vs. losing a few messages (e.g. because the delivery threads can't keep up) then the answer is clear. That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Sanjiva. On Sun, Jun 5, 2011 at 7:53 AM, Amila Suriarachchi am...@wso2.com wrote: On Sun, Jun 5, 2011 at 7:41 AM, Srinath Perera srin...@wso2.com wrote: Amila is it a option to ship current eventing impl, but with in-memory or registry based delivery manager instad of Qpid based one? yes. But we have not test this in memory implementation extensively with authorization, multi tenancy etc .. Lets meet on Monday and discuss what to do. thanks, Amila. --Srinath On Sat, Jun 4, 2011 at 5:35 PM, Amila Suriarachchi am...@wso2.com wrote: On Sat, Jun 4, 2011 at 4:13 PM, Senaka Fernando sen...@wso2.com wrote: Hi all, Just a thought. On Sat, Jun 4, 2011 at 3:10 PM, Tharindu Mathew thari...@wso2.com wrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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 minSpareThreads25/minSpareThreads maxThreads150/maxThreads maxQueuedRequests100/maxQueuedRequests keepAliveTime1000/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 subscriptionStoragePathevent/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
Re: [Carbon-dev] Removing event feature from most products
On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.com wrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Mon, Jun 6, 2011 at 8:36 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Sun, Jun 5, 2011 at 5:11 PM, Tharindu Mathew thari...@wso2.com wrote: That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. +1, for this model. The publisher that is used in Stratos is already done in a non blocking way. I feel it's better to go for the jdbc model. Tharindu what is the JDBC model?? We don't need persistence for these messages, so where does JDBC come into the picture? In the publisher, Hiranya wrote, we directly inject the event into the 'BAM' DB. This is what I referred to as the jdbc model. Instead of sending an event to BAM, and then inserting to the BAM DB. This option is also provided, which is what we use by default. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/ Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
[Carbon-dev] Removing event feature from most products
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? -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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 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: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
Hi all, Just a thought. On Sat, Jun 4, 2011 at 3:10 PM, Tharindu Mathew thari...@wso2.com wrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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? 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: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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? I programmed the deployment synchronizer in a way so that use of eventing is optional. It still has a mandatory OSGi dependency on registry eventing service but that can be made optional if needed. However in ESB we have now replaced the Synapse event sources with the new eventing implementation. We have programmed out event publisher mediator to work with the eventing component. Thanks, Hiranya -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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? No. All the components which uses event use the new this event API and hence all those projects require Qpid. But in the event design point of view it is possible to use an registry based implementation instead of Qpid on those products and shift the Qpid based implementaion only with MB and CEP. But I am realy concern about the time line we have to do such a drastic change. thanks, Amila. -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
If you look at most products, the only reason event component is there is for publishing BAM messages. As per yesterday's discussion, having the entire event component is overkill, and it does not work anyway when there is a high load. So, for Stratos we have to fix this. Removing something that does not work will be good for the release. This will reduce our product sizes by quite a bit too. On Sat, Jun 4, 2011 at 5:44 PM, Amila Suriarachchi am...@wso2.com wrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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? No. All the components which uses event use the new this event API and hence all those projects require Qpid. But in the event design point of view it is possible to use an registry based implementation instead of Qpid on those products and shift the Qpid based implementaion only with MB and CEP. But I am realy concern about the time line we have to do such a drastic change. thanks, Amila. -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Sat, Jun 4, 2011 at 6:21 PM, Afkham Azeez az...@wso2.com wrote: If you look at most products, the only reason event component is there is for publishing BAM messages. As per yesterday's discussion, having the entire event component is overkill, and it does not work anyway when there is a high load. So, for Stratos we have to fix this. Removing something that does not work will be good for the release. This will reduce our product sizes by quite a bit too. Removing event from BAM is one thing. Using an registry based implementation by default (which prevent shipping Qpid with each product) with event component is another thing. if we do the latter. I think we haven't done enough testing with the immemory implementation. thanks, Amila. On Sat, Jun 4, 2011 at 5:44 PM, Amila Suriarachchi am...@wso2.com wrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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? No. All the components which uses event use the new this event API and hence all those projects require Qpid. But in the event design point of view it is possible to use an registry based implementation instead of Qpid on those products and shift the Qpid based implementaion only with MB and CEP. But I am realy concern about the time line we have to do such a drastic change. thanks, Amila. -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
On Sat, Jun 4, 2011 at 6:57 PM, Amila Suriarachchi am...@wso2.com wrote: On Sat, Jun 4, 2011 at 6:21 PM, Afkham Azeez az...@wso2.com wrote: If you look at most products, the only reason event component is there is for publishing BAM messages. As per yesterday's discussion, having the entire event component is overkill, and it does not work anyway when there is a high load. So, for Stratos we have to fix this. Removing something that does not work will be good for the release. This will reduce our product sizes by quite a bit too. Removing event from BAM is one thing. Using an registry based implementation by default (which prevent shipping Qpid with each product) with event component is another thing. This is a P2 feature. If it is needed it can be installed. We are not using P2 effectively, we are packing everything into all products now the average product size is 200MB. Besides, this QPid based thing does not work anyway, it causes the server to go out of memory, so we cannot use this anyway in production. if we do the latter. I think we haven't done enough testing with the immemory implementation. thanks, Amila. On Sat, Jun 4, 2011 at 5:44 PM, Amila Suriarachchi am...@wso2.comwrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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? No. All the components which uses event use the new this event API and hence all those projects require Qpid. But in the event design point of view it is possible to use an registry based implementation instead of Qpid on those products and shift the Qpid based implementaion only with MB and CEP. But I am realy concern about the time line we have to do such a drastic change. thanks, Amila. -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] Removing event feature from most products
Amila is it a option to ship current eventing impl, but with in-memory or registry based delivery manager instad of Qpid based one? --Srinath On Sat, Jun 4, 2011 at 5:35 PM, Amila Suriarachchi am...@wso2.com wrote: On Sat, Jun 4, 2011 at 4:13 PM, Senaka Fernando sen...@wso2.com wrote: Hi all, Just a thought. On Sat, Jun 4, 2011 at 3:10 PM, Tharindu Mathew thari...@wso2.com wrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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 minSpareThreads25/minSpareThreads maxThreads150/maxThreads maxQueuedRequests100/maxQueuedRequests keepAliveTime1000/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 subscriptionStoragePathevent/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/ email: az...@wso2.com cell: +94 77 3320919 blog: http://blog.afkham.org twitter: http://twitter.com/afkham_azeez linked-in: http://lk.linkedin.com/in/afkhamazeez Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev ___
Re: [Carbon-dev] Removing event feature from most products
On Sun, Jun 5, 2011 at 7:41 AM, Srinath Perera srin...@wso2.com wrote: Amila is it a option to ship current eventing impl, but with in-memory or registry based delivery manager instad of Qpid based one? yes. But we have not test this in memory implementation extensively with authorization, multi tenancy etc .. Lets meet on Monday and discuss what to do. thanks, Amila. --Srinath On Sat, Jun 4, 2011 at 5:35 PM, Amila Suriarachchi am...@wso2.com wrote: On Sat, Jun 4, 2011 at 4:13 PM, Senaka Fernando sen...@wso2.com wrote: Hi all, Just a thought. On Sat, Jun 4, 2011 at 3:10 PM, Tharindu Mathew thari...@wso2.com wrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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 minSpareThreads25/minSpareThreads maxThreads150/maxThreads maxQueuedRequests100/maxQueuedRequests keepAliveTime1000/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 subscriptionStoragePathevent/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/ email: az...@wso2.com cell: +94 77 3320919 blog: http://blog.afkham.org twitter: http://twitter.com/afkham_azeez linked-in: http://lk.linkedin.com/in/afkhamazeez Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Regards, Tharindu ___ Carbon-dev mailing list Carbon-dev@wso2.org 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
Re: [Carbon-dev] Removing event feature from most products
I'd like to come for this discussion too please. On Azeez's proposal- he's not suggesting removing the Qpid based event broker from products that have event publishing as a feature. Those are G-Reg, DSS and ESB AFAIK. Those products will continue to use the broker. However all products have the BAM publisher to push information out to the BAM server. The suggestion is to change so that ALL products (including the 3 listed above) use a different BAM publishing codebase and not use the event broker to publish BAM data. BAM publishing has NOTHING to do with eventing- all that's needed is for the publication to happen on a low priority threadpool and for the initial recording of information to be non-blocking to the max. Furthermore the server should NEVER be able to crash while trying to publish data to BAM. Ideally it should never lose any messages but if the choice is between having the publishing stuff grow to a point of threatening the health of the server vs. losing a few messages (e.g. because the delivery threads can't keep up) then the answer is clear. That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. Sanjiva. On Sun, Jun 5, 2011 at 7:53 AM, Amila Suriarachchi am...@wso2.com wrote: On Sun, Jun 5, 2011 at 7:41 AM, Srinath Perera srin...@wso2.com wrote: Amila is it a option to ship current eventing impl, but with in-memory or registry based delivery manager instad of Qpid based one? yes. But we have not test this in memory implementation extensively with authorization, multi tenancy etc .. Lets meet on Monday and discuss what to do. thanks, Amila. --Srinath On Sat, Jun 4, 2011 at 5:35 PM, Amila Suriarachchi am...@wso2.com wrote: On Sat, Jun 4, 2011 at 4:13 PM, Senaka Fernando sen...@wso2.com wrote: Hi all, Just a thought. On Sat, Jun 4, 2011 at 3:10 PM, Tharindu Mathew thari...@wso2.com wrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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 minSpareThreads25/minSpareThreads maxThreads150/maxThreads maxQueuedRequests100/maxQueuedRequests keepAliveTime1000/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 subscriptionStoragePathevent/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
Re: [Carbon-dev] Removing event feature from most products
On Sun, Jun 5, 2011 at 8:20 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: I'd like to come for this discussion too please. On Azeez's proposal- he's not suggesting removing the Qpid based event broker from products that have event publishing as a feature. Those are G-Reg, DSS and ESB AFAIK. Those products will continue to use the broker. However all products have the BAM publisher to push information out to the BAM server. The suggestion is to change so that ALL products (including the 3 listed above) use a different BAM publishing codebase and not use the event broker to publish BAM data. BAM publishing has NOTHING to do with eventing- all that's needed is for the publication to happen on a low priority threadpool and for the initial recording of information to be non-blocking to the max. Furthermore the server should NEVER be able to crash while trying to publish data to BAM. Ideally it should never lose any messages but if the choice is between having the publishing stuff grow to a point of threatening the health of the server vs. losing a few messages (e.g. because the delivery threads can't keep up) then the answer is clear. +1. So this change has nothing to do with event implementation. Only BAM publishers have to directly push messages to BAM MessageReceiver instead of going through and event broker (which is obviously in efficient as you have pointed out). thanks, Amila. That can be achieved by using a simple non-blocking Axis2 sender type thing - which I believe is what Hiranya wrote a while ago. The BAM server needs to be set up in a clustered manner with an LB etc. to handle the large number of messages it will receive when Stratos is running at full tilt (and have additional load balancing things like DNS round-robin). We can make that work easily. Sanjiva. On Sun, Jun 5, 2011 at 7:53 AM, Amila Suriarachchi am...@wso2.com wrote: On Sun, Jun 5, 2011 at 7:41 AM, Srinath Perera srin...@wso2.com wrote: Amila is it a option to ship current eventing impl, but with in-memory or registry based delivery manager instad of Qpid based one? yes. But we have not test this in memory implementation extensively with authorization, multi tenancy etc .. Lets meet on Monday and discuss what to do. thanks, Amila. --Srinath On Sat, Jun 4, 2011 at 5:35 PM, Amila Suriarachchi am...@wso2.com wrote: On Sat, Jun 4, 2011 at 4:13 PM, Senaka Fernando sen...@wso2.com wrote: Hi all, Just a thought. On Sat, Jun 4, 2011 at 3:10 PM, Tharindu Mathew thari...@wso2.com wrote: On Sat, Jun 4, 2011 at 11:50 AM, Afkham Azeez az...@wso2.com 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 minSpareThreads25/minSpareThreads maxThreads150/maxThreads maxQueuedRequests100/maxQueuedRequests keepAliveTime1000/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 subscriptionStoragePathevent/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
