On Fri, Mar 18, 2011 at 8:50 PM, Senaka Fernando <sen...@wso2.com> wrote:
> > > On Fri, Mar 18, 2011 at 8:08 PM, Amila Suriarachchi <am...@wso2.com>wrote: > >> >> >> On Fri, Mar 18, 2011 at 7:11 PM, Paul Fremantle <p...@wso2.com> 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? > Please look at the handleConsume method here[1]. It access the registry to check whether the user is the owner. But actually this check is not need and at the queue creation time we can add the all the permissions to the user and after that we can just check the permission to the user. thanks, Amila. [1] https://svn.wso2.org/repos/wso2/trunk/carbon/components/qpid/org.wso2.carbon.qpid.authorization/src/main/java/org/wso2/carbon/qpid/authorization/qpid/QpidAuthorizationHandler.java > > 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 <am...@wso2.com> wrote: >>> >>>> >>>> >>>> On Wed, Mar 16, 2011 at 4:40 PM, Paul Fremantle <p...@wso2.com> 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 >>>>> p...@wso2.com >>>>> >>>>> 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 >>>>> Carbon-dev@wso2.org >>>>> 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 >>> p...@wso2.com >>> >>> 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 >> 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://www.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
