On Thu, Apr 7, 2011 at 5:50 PM, Kasun Indrasiri <[email protected]> wrote:
> Hi all,
>
> I've tested a latest ESB build with the fix for qpid. The registry issues
> seems to be resolved.
>
We need to be sure, because the same build that failed before did not
reproduce the errors on my machine or while running some integration tests
on the builder, so it was somewhat intermittent. So, we need to test this
fully, and especially on the private cloud.
Thanks,
Senaka.
> However getting the following warning.
> Will run a integration test cycle and invoke a build in the builder
> machine. Thanks Dhanushka for your help.
>
> [2011-04-07 17:44:19,837] WARN {org.apache.qpid.transport.ClientDelegate}
> - Ignoring the idle timeout 120 set by the connection, using the brokers
> max value 0
> [2011-04-07 17:44:20,091] WARN {org.apache.qpid.transport.SessionDelegate}
> - CLOSED: [ssn:"50c468d5-1629-488d-9a92-8be87c0ba0f0"]
> [2011-04-07 17:44:20,142] WARN {org.apache.qpid.transport.ClientDelegate}
> - Ignoring the idle timeout 120 set by the connection, using the brokers
> max value 0
> [2011-04-07 17:44:20,230] WARN {org.apache.qpid.transport.SessionDelegate}
> - CLOSED: [ssn:"f92cd18b-7b07-4d4d-9069-474ef8e3e0cb"]
> [2011-04-07 17:44:20,280] WARN {org.apache.qpid.transport.ClientDelegate}
> - Ignoring the idle timeout 120 set by the connection, using the brokers
> max value 0
> [2011-04-07 17:44:20,421] WARN {org.apache.qpid.transport.SessionDelegate}
> - CLOSED: [ssn:"a1903708-debd-425b-a49c-2383fbd93f88"]
> [2011-04-07 17:44:20,489] WARN {org.apache.qpid.transport.ClientDelegate}
> - Ignoring the idle timeout 120 set by the connection, using the brokers
> max value 0
> [2011-04-07 17:44:20,596] WARN {org.apache.qpid.transport.SessionDelegate}
> - CLOSED: [ssn:"00da45f2-fe88-4597-a307-6e69a8f7f093"]
> [2011-04-07 17:44:20,607] INFO
> {org.wso2.carbon.core.deployment.DeploymentInterceptor} - Deploying Axis2
> service: MBoardStatusProxy {super-tenant}
> [2011-04-07 17:44:20,660] WARN {org.apache.qpid.transport.ClientDelegate}
> - Ignoring the idle timeout 120 set by the connection, using the brokers
> max value 0
> [2011-04-07 17:44:20,789] WARN {org.apache.qpid.transport.SessionDelegate}
> - CLOSED: [ssn:"254016a7-1de5-44e6-a256-de5769e1c592"]
> [2011-04-07 17:44:20,833] WARN {org.apache.qpid.transport.ClientDelegate}
> - Ignoring the idle timeout 120 set by the connection, using the brokers
> max value 0
> [2011-04-07 17:44:20,938] WARN {org.apache.qpid.transport.SessionDelegate}
> - CLOSED: [ssn:"afb60974-d562-4323-b79f-bc36ea22d4d0"]
>
>
> On Thu, Apr 7, 2011 at 5:28 PM, Amila Suriarachchi <[email protected]> wrote:
>
>>
>>
>> On Thu, Apr 7, 2011 at 3:41 PM, Afkham Azeez <[email protected]> wrote:
>>
>>> User. Realm.service may not solve this
>>>
>> Why? you can always access the UserRealm using the
>> org.wso2.carbon.user.core.service.RealmService.
>>
>> thanks,
>> Amila.
>>
>>
>>> On Apr 7, 2011 3:38 PM, "Afkham Azeez" <[email protected]> wrote:
>>> > Yes, this method is what caused a huge performance issue in servlet
>>> > transport
>>> > On Apr 7, 2011 2:52 PM, "Danushka Menikkumbura" <[email protected]>
>>> wrote:
>>> >> Currently Qpid authorization plugin retrieves the user realm using
>>> >> registryService.getConfigUserRegistry().getUserRealm() which spends
>>> around
>>> >> 70% of the processing time. I am going to switch it to use the realm
>>> >> service. It should solve this issue.
>>> >>
>>> >> Danushka
>>> >>
>>> >> On Thu, Apr 7, 2011 at 2:13 PM, Supun Kamburugamuva <[email protected]>
>>> > wrote:
>>> >>
>>> >>> Is it possible to disable eventing for the moment and get this to a
>>> >>> working state? Because we are blocked on everything because of this.
>>> >>>
>>> >>> Thanks,
>>> >>> Supun..
>>> >>>
>>> >>> On Thu, Apr 7, 2011 at 12:19 PM, Senaka Fernando <[email protected]>
>>> wrote:
>>> >>> > Hi Danushka,
>>> >>> >
>>> >>> > On Thu, Apr 7, 2011 at 7:18 AM, Danushka Menikkumbura <
>>> > [email protected]
>>> >>> >
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Also if this particular call is costly we can optimise some of
>>> them.
>>> > But
>>> >>> I
>>> >>> >> think it is supposed to be used quite often. Isn't it?
>>> >>> >
>>> >>> > Yes. IMHO, the optimization could be done at the event-component
>>> level
>>> >>> > right, to avoid an unwanted call to Qpid. The publishers would
>>> generate
>>> >>> > events whenever some thing interesting happens and forward it to
>>> the
>>> >>> broker.
>>> >>> > These go through the event component which manages the brokering,
>>> and
>>> >>> then
>>> >>> > comes into Qpid for routing. So, if we could make the event
>>> component a
>>> >>> bit
>>> >>> > more intelligent to only forward messages to Qpid if needed (some
>>> form
>>> > of
>>> >>> > caching is needed), we should be able to avoid this right?
>>> >>> >
>>> >>> > WDYT?
>>> >>> >
>>> >>> > Thanks,
>>> >>> > Senaka.
>>> >>> >>
>>> >>> >> Danushka
>>> >>> >>
>>> >>> >> On Thu, Apr 7, 2011 at 6:41 AM, Danushka Menikkumbura <
>>> >>> [email protected]>
>>> >>> >> wrote:
>>> >>> >>>>
>>> >>> >>>> Why 'registryService.getConfigUserRegistry().getUserRealm();'
>>> > getting
>>> >>> >>>> too long to respond? This is a widely used statement available
>>> on
>>> > unit
>>> >>> >>>> tests. Are those failing as well? If not, why is this happening
>>> > during
>>> >>> >>>> runtime only?
>>> >>> >>>
>>> >>> >>> Yes. Senaka I think this is the issue that we need to address as
>>> I
>>> > can
>>> >>> >>> see.
>>> >>> >>>
>>> >>> >>> Danushka
>>> >>> >>>
>>> >>> >>
>>> >>> >>
>>> >>> >> _______________________________________________
>>> >>> >> 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
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Supun Kamburugamuva
>>> >>> Technical Lead & Product Manager, WSO2 Inc.; http://wso2.com
>>> >>> Member, Apache Software Foundation; http://www.apache.org
>>> >>> WSO2 Inc.; http://wso2.org
>>> >>> E-mail: [email protected]; Mobile: +94 77 431 3585
>>> >>> Blog: http://supunk.blogspot.com
>>> >>> _______________________________________________
>>> >>> Carbon-dev mailing list
>>> >>> [email protected]
>>> >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>> >>>
>>>
>>> _______________________________________________
>>> Carbon-dev mailing list
>>> [email protected]
>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>
>>>
>>
>> _______________________________________________
>> Carbon-dev mailing list
>> [email protected]
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
>
>
> --
> Kasun Indrasiri
> Senior Software Engineer
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 71 536 4128
> Blog : http://kasunpanorama.blogspot.com/
>
>
> _______________________________________________
> 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
