On Fri, Mar 18, 2011 at 8:08 PM, Amila Suriarachchi <[email protected]> wrote:
> > > On Fri, Mar 18, 2011 at 7:11 PM, Paul Fremantle <[email protected]> wrote: > >> I've just built the ESB too and I'll have a look. >> >> >> Right now I've got the ESB 3.0.1 and MB working separately and that looks >> fine. I'm seeing MB stabilize at about 700Mb of memory. I'm not getting very >> exciting throughput. I've got curl sending requests to the ESB which is >> dumping messages into MB and then a standalone JMS client is picking them >> up. I'm seeing about 60msg/sec at the Java client. >> > > This may because authentication and authorization. Which access the user > manager and registry. > Why access registry for authentication and authorization? Thanks, Senaka. > > thanks, > Amila. > > >> >> The message broker is taking about 70% of my CPU, 20% to the ESB, very >> little for curl or my Java JMS listener. >> >> Paul >> >> >> On 18 March 2011 13:01, Amila Suriarachchi <[email protected]> wrote: >> >>> >>> >>> On Wed, Mar 16, 2011 at 4:40 PM, Paul Fremantle <[email protected]> wrote: >>> >>>> 1. Discussed the need to support three scenarios: >>>> >>>> a) MB co-located inside ESB using p2 to install the component. There >>>> seems to be an issue with the client libs getting in the right place. >>>> Danushka is following up with Senaka. >>>> b) Standalone JMS client. We need a client library packaging. Amila is >>>> looking at this >>>> c) MB client in ESB, MB across the network. If possible this would be >>>> good to have a p2 feature for this. >>>> >>> >>> I build the ESB from the trunk. The current ESB comes with the new Event >>> component hence the embeded Qpid component. So no need to add an additional >>> jar files. >>> >>> I could successfully run the synapse-sample 251 with that attached >>> configuration files. I used the in embed Qpid server within ESB. >>> >>> This uses the jms endpoint like this >>> >>> <address >>> uri="jms:/SimpleStockQuoteService?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&java.naming.factory.initial=org.apache.qpid.jndi.PropertiesFileInitialContextFactory&java.naming.provider.url=/home/amila/downloads/temp/server.properties&transport.jms.DestinationType=queue"/> >>> >>> Do we need to go support the CarboncontextFactory jndi for this release? >>> >>> thanks, >>> Amila. >>> >>> >>>> >>>> 2) Not clear which JNDI we should be using. Seems like we have two or >>>> more JNDIs - QPid property based JNDI, Registry based JNDI (and also >>>> probably Tomcat JNDI). >>>> Action: Amila - please can you propose which JNDI we should use in >>>> scenario 1a) above. Scenario 1b) should use QPid's property based JNDI. >>>> >>>> 3) Issue with our SQS code not creating durable queues. Action is to try >>>> adding { attributes } to our create code to ensure it is durable. >>>> >>>> 4) SQS access key. 1) Dimuthu is working on getting this right. 2) We >>>> need to display the access key (even if its just the username) in the UI >>>> alongside the secret key. 3) test the Amazon sample client with a username >>>> longer than 20 digits >>>> >>>> 5) SQS permissions don't exactly match JMS permissions. So if a user >>>> sets a permission via SQS then someone using AMQP directly can bypass. >>>> Action: leave as-is and document. If someone really cares then they need to >>>> block AMQP access to SQS users. >>>> >>>> 6) Memory Leak: needs to be fixed asap: Danushka on it >>>> >>>> 7) User based permissions for SQS: need to change the UI so it doesn't >>>> just list users. Action: Amila is looking at this. >>>> >>>> 8) List Queues/Queue based management: needs role-based permissions. >>>> Amila is looking at this. >>>> >>>> 9) TLS: this is needed by CSG. For MB its obviously important, but if we >>>> can't fix it by 1.0 then we will go ahead anyway and fix in a 1.01 or 1.1 >>>> shortly after. Action: Rajika to look at it. >>>> >>>> 10) H2. Try a simple test to see if H2 works. This is not highest >>>> priority, so lets fix everything else first. Ideally we really need MySQL >>>> since neither H2 not Derby are scalable. >>>> >>>> Amila is going to check with everyone to make sure they are all able to >>>> be productive. >>>> >>>> Paul will work on testing and documenting how it works with ESB. >>>> >>>> Paul >>>> >>>> -- >>>> Paul Fremantle >>>> CTO and Co-Founder, WSO2 >>>> OASIS WS-RX TC Co-chair, VP, Apache Synapse >>>> >>>> Office: +44 844 484 8143 >>>> Cell: +44 798 447 4618 >>>> >>>> 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. >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> [email protected] >>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>> >>>> >>> >> >> >> -- >> Paul Fremantle >> CTO and Co-Founder, WSO2 >> OASIS WS-RX TC Co-chair, VP, Apache Synapse >> >> Office: +44 844 484 8143 >> Cell: +44 798 447 4618 >> >> 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. >> > > > _______________________________________________ > 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://www.linkedin.com/in/senakafernando *Lean . Enterprise . Middleware
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
