Hi all,
I spent some time on debugging this issue at several levels including
repositoryAdminService client & stub, localTransport and addressing.
AFAIU the root cause is at addressing level where axis2 is unable to
process the addressing headers for the addRepository request when
localTransport is enabled in AS.
In org.apache.axis2.handlers.addressing.AddressingInHandler.doInvoke() the
header blocks are extracted as below;
iterator = header.getHeadersToProcess(rolePlayer, namespace);
Initially I thought the problem is with the namespace of the headers but it
was not the case. The problem is with the soap rolePlayer. I observed in
AppServer that rolePlayer is initialized with role: *supertenant*. When
supertant is set as the SOAP role header.getHeadersToProcess(rolePlayer,
namespace) doesn't process the header blocks so the server just treats the
message as a normal message without headers and sends the response without
any addressing information. That is why the callback is not triggered when
the response comes.
In carbon 4.0.1, 4.0.2 the role is not set as supertenant, The roleplayer
is always null. I observed the same behaviour in greg-4.5.0.
So In carbon, greg this works properly regardless of localTransport is
enabled or disabled.
The roleplayer is initialized in AddressingInHandler.doInvoke() as below
using AxisConfiguration;
if(configuration == null){
System.out.println("axis config is null creating new one..");
AxisConfiguration conf =
msgContext.getConfigurationContext().getAxisConfiguration();
rolePlayer =
(RolePlayer)conf.getParameterValue(Constants.SOAP_ROLE_PLAYER_PARAMETER);
configuration = conf;
}
Any suggestions on how to resolve this issue with soap role : supertenant ?
Thanks,
Dileepa
On Wed, Oct 3, 2012 at 1:15 AM, Dileepa Jayakody <[email protected]> wrote:
> Hi All,
>
> I could reproduce this issue in esb 4.5.0 as well, so it's not limited to
> AS.
>
> When debugging the featureManager code what I observed is
> RepositoryAdminServiceCallbackHandler object registered for the
> addRepository asynchronous service request in RepositoryAdminServiceClient
> doesn't receive the response from the backend service.
> The handleCallback() waits forever till the callback handler receives the
> response from the BE service, hence the feature manager UI thread appears
> to be stuck.
>
> However if I disable the local transport by setting ServerURL as
> https://${carbon.local.ip}:${carbon.management.port}${carbon.context}/services/
> in carbon.xml, the callbackhandler receives the service response for the
> above asynch call and the addRepository action completes without taking
> much time.
>
> Could this be an issue with local transport and WS-addressing where it is
> causing trouble for asynchronous clients to receive service response?
>
>
> Thanks,
> Dileepa
>
>
>
>
> On Mon, Oct 1, 2012 at 5:09 PM, Supun Malinga <[email protected]> wrote:
>
>> Hi,
>>
>> On Mon, Oct 1, 2012 at 3:57 PM, Dileepa Jayakody <[email protected]>wrote:
>>
>>> Hi Rajika and all,
>>>
>>> This issue with adding a p2-repo getting stuck is reproduced in AS 5.0.
>>> The issue is not there in kernel, esb-4.5.0 etc. Another thing to note is
>>> although the ui thread gets stuck, if we restart AS after a sufficient time
>>> for a repo-add or feature installation request, we can see the request has
>>> been fulfilled from the feature manager BE after the restart.
>>>
>>
>> I too observed this in AS. The installation task/ repo adding task
>> completion notifications doesn't appear.
>>
>> thanks,
>>
>>>
>>> This could be an issue with CallBackHandlers for feature manager
>>> requests. But what I cannot understand is why is it only happening in AS,
>>> because feature-manager component is common to all products.
>>> Any ideas?
>>>
>>> Thanks,
>>> Dileepa
>>>
>>> On Mon, Sep 10, 2012 at 9:06 PM, Chethiya Abeysinghe
>>> <[email protected]>wrote:
>>>
>>>> OK. Got it. We can reason out loading meta data of all the features to
>>>> the memory for computing the dependency tree. But I don't think that needs
>>>> feature artifacts to be loaded into memory too.
>>>> I guess how it works is, first it hash all features in memory and then
>>>> create dependency tree for the user selected features efficiently f
>>>>
>>>>> Yes Chethiya p2 computes the dependencies before installing features.
>>>>> It is called a provisioning plan.
>>>>>
>>>>> But Rajika's concern is that it's taking a long time at repository
>>>>> adding stage, which should not be performing any dependency computations.
>>>>> But I suspect p2 might be loading all the features in the repo to memory
>>>>> at
>>>>> this stage. Have to clarify with p2-dev.
>>>>>
>>>>> Thanks,
>>>>> Dileepa
>>>>>
>>>>> On Mon, Sep 10, 2012 at 5:47 PM, Chethiya Abeysinghe <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> AFAIK, installing a p2 feature means not just copying set of files.
>>>>>> It computes required dependency trees too. Looking at the content.xml I
>>>>>> think it can take sometime for computation. But always better to check
>>>>>> with
>>>>>> p2-dev as there can be cases which can be configured to
>>>>>> avoid unnecessary dependency checks.
>>>>>>
>>>>>> - Chethiya
>>>>>>
>>>>>> On Mon, Sep 10, 2012 at 4:37 PM, Dileepa Jayakody
>>>>>> <[email protected]>wrote:
>>>>>>
>>>>>>> Hi Rajika,
>>>>>>>
>>>>>>> Thanks for the pointers.
>>>>>>> In the feature-manager we are using p2 sdk, calling the p2-api under
>>>>>>> the hood.
>>>>>>>
>>>>>>> For eg: to add and load a repository following code is used by us.
>>>>>>>
>>>>>>> IMetadataRepositoryManager metadataRepositoryManager =
>>>>>>> ServiceHolder.getMetadataRepositoryManager();
>>>>>>> IArtifactRepositoryManager artifactRepositoryManager =
>>>>>>> ServiceHolder.getArtifactRepositoryManager();
>>>>>>>
>>>>>>> //adding metadata and artifact repositories
>>>>>>> metadataRepositoryManager.addRepository(location);
>>>>>>> artifactRepositoryManager.addRepository(location);
>>>>>>> //Loading the metadata repository
>>>>>>> metadataRepositoryManager.loadRepository(location, new
>>>>>>> NullProgressMonitor());
>>>>>>>
>>>>>>> metadataRepositoryManager.setRepositoryProperty(location,
>>>>>>> IRepository.PROP_NICKNAME, nickName);
>>>>>>>
>>>>>>> //Loading the artifact repository
>>>>>>> artifactRepositoryManager.loadRepository(location, new
>>>>>>> NullProgressMonitor());
>>>>>>>
>>>>>>> artifactRepositoryManager.setRepositoryProperty(location,
>>>>>>> IRepository.PROP_NICKNAME, nickName);
>>>>>>>
>>>>>>> First we need to clarify how p2-works under the hood when loading a
>>>>>>> repository from a given location.
>>>>>>> Ideally it should just index the feature list by reading the the
>>>>>>> repository's content.xml and artifacts.xml at this point without loading
>>>>>>> all the features to the memory ( I believe this is what you are also
>>>>>>> suggesting).
>>>>>>> I will discuss this with p2-dev also and see how we can improve our
>>>>>>> feature manager based on that.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dileepa
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 10, 2012 at 4:12 PM, Rajika Kumarasiri
>>>>>>> <[email protected]>wrote:
>>>>>>>
>>>>>>>> I meant the consumer task should do the feature installation
>>>>>>>> asynchronously.
>>>>>>>>
>>>>>>>> Rajika
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Sep 10, 2012 at 3:54 PM, Rajika Kumarasiri <[email protected]
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> If you have not done already, here how it should be done.
>>>>>>>>>
>>>>>>>>> There should be an instance of blocking queue instance which keeps
>>>>>>>>> track of requested features to install. There should be a producer
>>>>>>>>> task
>>>>>>>>> which drop next requested feature list to install into the blocking
>>>>>>>>> queue.
>>>>>>>>> There should be a consumer task will remove items from the blocking
>>>>>>>>> queue.
>>>>>>>>> For producing and consuming use
>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html#put<http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html#put%28E%29>
>>>>>>>>> and
>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html#take()
>>>>>>>>> so
>>>>>>>>> that your consumer and producer task will not kill the CPU.
>>>>>>>>>
>>>>>>>>> Since Feature manager will not use frequently this model may not
>>>>>>>>> make sense much, but I think it will be useful when our p2 feature
>>>>>>>>> repository starts to grow.
>>>>>>>>>
>>>>>>>>> Hope this helps.
>>>>>>>>>
>>>>>>>>> Rajika
>>>>>>>>>
>>>>>>>>> On Mon, Sep 10, 2012 at 2:47 PM, Dileepa Jayakody <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Rajika,
>>>>>>>>>>
>>>>>>>>>> Is the repository you are adding a local-repository or a remote
>>>>>>>>>> repository?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dileepa
>>>>>>>>>>
>>>>>>>>>> On Mon, Sep 10, 2012 at 2:44 PM, Rajika Kumarasiri <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> I just tried to add the feature repository of 4.0.1 into a AS
>>>>>>>>>>> (built from 4.0.1 branch) and it seems it just take too much time.
>>>>>>>>>>>
>>>>>>>>>>> I still can see the message "Adding repository.." and it just
>>>>>>>>>>> there.
>>>>>>>>>>>
>>>>>>>>>>> This need to improve. We just need to load the list features
>>>>>>>>>>> (just names) and install any selected features asynchronously.
>>>>>>>>>>>
>>>>>>>>>>> It seems this loads the whole features into memory.
>>>>>>>>>>>
>>>>>>>>>>> Rajika
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Dev mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Dileepa Jayakody,
>>>>>>>>>> Software Engineer, WSO2 Inc.
>>>>>>>>>> Lean . Enterprise . Middleware
>>>>>>>>>>
>>>>>>>>>> Mobile : +94777-857616
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Dileepa Jayakody,
>>>>>>> Software Engineer, WSO2 Inc.
>>>>>>> Lean . Enterprise . Middleware
>>>>>>>
>>>>>>> Mobile : +94777-857616
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dev mailing list
>>>>>>> [email protected]
>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Chethiya Abeysinghe
>>>>>> Software Engineer; WSO2, Inc.; http://wso2.com/
>>>>>> email: [email protected] phone: +94 777444891
>>>>>> blog: chethiya3000.blogspot.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dileepa Jayakody,
>>>>> Software Engineer, WSO2 Inc.
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> Mobile : +94777-857616
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Dileepa Jayakody,
>>> Software Engineer, WSO2 Inc.
>>> Lean . Enterprise . Middleware
>>>
>>> Mobile : +94777-857616
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [email protected]
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Supun Malinga,
>>
>> Software Engineer,
>> WSO2 Inc.
>> http://wso2.com
>> http://wso2.org
>> email - [email protected] <[email protected]>
>> mobile - 071 56 91 321
>>
>>
>
>
> --
> Dileepa Jayakody,
> Software Engineer, WSO2 Inc.
> Lean . Enterprise . Middleware
>
> Mobile : +94777-857616
>
>
--
Dileepa Jayakody,
Software Engineer, WSO2 Inc.
Lean . Enterprise . Middleware
Mobile : +94777-857616
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
