We still see this issue in the latest packs. We need to fix this or
recommend users to disable LT when installing P2-features.
/Charitha
On Fri, Oct 12, 2012 at 8:22 AM, Amila Suriarachchi am...@wso2.com wrote:
I think we need to thing the problem from the beginning.
We use this dual channel
On Fri, Oct 12, 2012 at 11:55 AM, Charitha Kankanamge chari...@wso2.comwrote:
We still see this issue in the latest packs. We need to fix this or
recommend users to disable LT when installing P2-features.
Disabling LT only for the sake of installing P2 does not seem right :(
/Charitha
AFAIK,
dileepa has a fix. He will commit it EOD today.
On Fri, Oct 12, 2012 at 11:57 AM, Samisa Abeysinghe sam...@wso2.com wrote:
On Fri, Oct 12, 2012 at 11:55 AM, Charitha Kankanamge chari...@wso2.com
wrote:
We still see this issue in the latest packs. We need to fix this or
recommend
On Fri, Oct 12, 2012 at 8:22 AM, Amila Suriarachchi am...@wso2.com wrote:
I think we need to thing the problem from the beginning.
We use this dual channel technique for this to avoid http connection time
outs. We use addressing order to send the reply in a separate channel
(using addressing
On Thu, Oct 11, 2012 at 7:08 AM, Pradeep Fernando prad...@wso2.com wrote:
May be this is a regression due to product/service merge. I see a
related class [1].
[1]
Hi,
what if we populate the carbonContext upon receiving the context. This
is the exact thing that happens in servletTransport
(CarbonContextCreator).
The context information get lost due to spawning of a another thread.
The other workaround would be to set the existing CarbonContextDetails
On Fri, Oct 12, 2012 at 7:55 AM, Pradeep Fernando prad...@wso2.com wrote:
Hi,
what if we populate the carbonContext upon receiving the context. This
is the exact thing that happens in servletTransport
(CarbonContextCreator).
The context information get lost due to spawning of a another
I think we need to thing the problem from the beginning.
We use this dual channel technique for this to avoid http connection time
outs. We use addressing order to send the reply in a separate channel
(using addressing replyTo header) to avoid time outs of thread that invokes
the stub.
With
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
May be this is a regression due to product/service merge. I see a
related class [1].
[1]
carbon/platform/trunk/components/stratos/org.wso2.carbon.stratos.deployment/src/main/java/org/wso2/carbon/stratos/deployment/SuperTenantRolePlayer.java
--Pradeep
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
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
One thing you can do is to get a thread dump and analyze it to see if that
particular thread is really stuck and not doing any useful work(or why at
least it seems to be so).
Rajika
On Mon, Oct 1, 2012 at 3:57 PM, Dileepa Jayakody dile...@wso2.com wrote:
Hi Rajika and all,
This issue with
Hi,
On Mon, Oct 1, 2012 at 3:57 PM, Dileepa Jayakody dile...@wso2.com 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
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
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 raj...@wso2.com 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
It's a local repository. I download the repository into my local file
system.
Rajika
On Mon, Sep 10, 2012 at 2:47 PM, Dileepa Jayakody dile...@wso2.com wrote:
Hi Rajika,
Is the repository you are adding a local-repository or a remote repository?
Thanks,
Dileepa
On Mon, Sep 10, 2012 at
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
I meant the consumer task should do the feature installation
asynchronously.
Rajika
On Mon, Sep 10, 2012 at 3:54 PM, Rajika Kumarasiri raj...@wso2.com 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
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();
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
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
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
23 matches
Mail list logo
