The broker actually does not support heartbeats and both max and min values for heartbeat interval are hard coded to 0. That is why you see this warning. I can not reproduce this and need to debug in your setup to see how you get the 120 value. Anyways when I go through the code what I see is that this is a harmless warning.
Danushka On Fri, Apr 8, 2011 at 6:58 AM, Danushka Menikkumbura <[email protected]>wrote: > The reason for this warning is not having the heartbeat interval defined > within the range specified in the AMQP specification. It should be a simple > configuration change. I will take a look. Anyway this does not affect the > functionality. > > Danushka > > > On Thu, Apr 7, 2011 at 10:18 PM, Kasun Weranga <[email protected]> wrote: > >> Hi, >> >> 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. 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 <[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 >>> >>> >> >> >> -- >> *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 >> [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
