Hi,
On Thu, Apr 7, 2011 at 5:50 PM, Kasun Indrasiri <ka...@wso2.com> wrote:
> Hi all,
>
> I've tested a latest ESB build with the fix for qpid. The registry issues
> seems to be resolved. 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"]
>
>
We are also getting these warnings while appserver publishing events to BAM
side using event broker, we can see lots of warning messages printed on
appserver console.
Thanks,
KasunW.
>
> On Thu, Apr 7, 2011 at 5:28 PM, Amila Suriarachchi <am...@wso2.com> wrote:
>
>>
>>
>> On Thu, Apr 7, 2011 at 3:41 PM, Afkham Azeez <az...@wso2.com> 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" <az...@wso2.com> wrote:
>>> > Yes, this method is what caused a huge performance issue in servlet
>>> > transport
>>> > On Apr 7, 2011 2:52 PM, "Danushka Menikkumbura" <danus...@wso2.com>
>>> 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 <su...@wso2.com>
>>> > 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 <sen...@wso2.com>
>>> wrote:
>>> >>> > Hi Danushka,
>>> >>> >
>>> >>> > On Thu, Apr 7, 2011 at 7:18 AM, Danushka Menikkumbura <
>>> > danus...@wso2.com
>>> >>> >
>>> >>> > 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 <
>>> >>> danus...@wso2.com>
>>> >>> >> 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
>>> >>> >> 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
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> 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: su...@wso2.com; Mobile: +94 77 431 3585
>>> >>> Blog: http://supunk.blogspot.com
>>> >>> _______________________________________________
>>> >>> 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
>>
>>
>
>
> --
> 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
> Carbon-dev@wso2.org
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>
--
*Kasun Weranga*
Software Engineer
**
*WSO2, Inc.
*lean.enterprise.middleware.
mobile : +94 772314602
<http://sanjeewamalalgoda.blogspot.com/>blog
:<http://sanjeewamalalgoda.blogspot.com/>
http://kasunweranga.blogspot.com/
_______________________________________________
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
