Hi,
I too can see the same WARNING message on the console,
[2011-04-07 16:33:02,227] INFO
{org.wso2.carbon.core.transports.http.HttpsTransportListener} - HTTPS port
: 9443
[2011-04-07 16:33:02,228] INFO
{org.wso2.carbon.core.transports.http.HttpTransportListener} - HTTP port
: 9763
[Broker] BRK-1006 : Using configuration :
/home/fazlan/products/wso2greg-4.0.0-SNAPSHOT/repository/conf/advanced/qpid-config.xml
Logging configuration error: unable to read file
/home/fazlan/products/wso2greg-4.0.0-SNAPSHOT/repository/conf/advanced/log4j.xml
Using the fallback internal log4j.properties configuration
[Broker] BRK-1001 : Startup : Version: 0.11 Build: 90784:90849
[Broker] MNG-1001 : Startup
[Broker] MNG-1004 : Ready : Using the platform JMX Agent
[Broker] BRK-1002 : Starting : Listening on TCP port 5672
[Broker] BRK-1004 : Qpid Broker Ready
[2011-04-07 16:33:05,056] INFO
{org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet} -
resource-path-prefix = ''
[2011-04-07 16:33:05,056] INFO
{org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet} -
WWW-Authenticate header = 'Basic realm="Jackrabbit Webdav Server"'
Starting registry Servlet
[2011-04-07 16:33:07,284] INFO
{org.wso2.carbon.ui.internal.CarbonUIServiceComponent} - Mgt Console URL :
https://10.100.0.149:9443/carbon/
[2011-04-07 16:33:07,309] INFO
{org.wso2.carbon.event.core.internal.builder.EventBrokerBuilderDS} -
Successfully registered the event broker
[2011-04-07 16:33:07,318] INFO
{org.wso2.carbon.core.internal.StartupFinalizerServiceComponent} - Started
Transport Listener Manager
[2011-04-07 16:33:07,318] INFO
{org.wso2.carbon.core.internal.StartupFinalizerServiceComponent} - Server
: WSO2 Governance Registry-4.0.0-SNAPSHOT
[2011-04-07 16:33:07,318] INFO
{org.wso2.carbon.core.internal.StartupFinalizerServiceComponent} - WSO2
Carbon started in 30 sec
[2011-04-07 16:47:38,079] INFO
{org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - 'admin'
logged in at [2011-04-07 16:47:38,0079] from IP address
[2011-04-07 16:47:47,945] WARN
{org.apache.directory.server.core.normalization.FilterNormalizingVisitor} -
Failed to normalize filter value: ERR_04201 No more characters available at
position 4
[2011-04-07 16:47:47,945] WARN
{org.apache.directory.server.core.normalization.NormalizationInterceptor} -
undefined filter based on undefined attributeType not evaluted at all.
Returning empty enumeration.
*[2011-04-07 16:47:48,540] WARN {org.apache.qpid.transport.ClientDelegate}
- Ignoring the idle timeout 120 set by the connection, using the brokers
max value 0*
On Thu, Apr 7, 2011 at 6:21 PM, Senaka Fernando <[email protected]> wrote:
>
>
> 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
>
>
--
Thanks,
Fazlan
_______________________________________________
Carbon-dev mailing list
[email protected]
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
