[
https://issues.apache.org/jira/browse/KARAF-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17899227#comment-17899227
]
Darrel Riekhof edited comment on KARAF-7881 at 11/18/24 6:26 PM:
-----------------------------------------------------------------
We never really pinpointed the source of the problem but found a workaround
that prevents the hangs, at least we haven't seen a hang since implementing
this workaround.
We were including a few dependencies in our service jar that were already
provided by Karaf. In particular, we were including all the the camel libs our
project needed as well as some common-* libs, jakarata-xml, log4j,
fasterxml.jackson, etc. In some cases the versions were the same, others
slightly different versions.
When we synced up all the versions we could with what's provided in karaf 4.4.6
and marked the dependency scopes as provided in our pom, then many were no
longer included in the service jar and it became signficantly smaller and the
hangs stopped happening. We noticed some libs were still being included even
though they were marked as provided and that was because they were transitive
dependencies on other dependencies and the maven plugins still included those
in the resulting jar. So we used the exclusion tag in the parent dependency to
also prevent those from being added to our service jar.
So my best guess is there is some risk of jars not re-deploying in karaf if
they have some mix of classes in them already provided in karaf. Or maybe
there is some risk of jars deployments hanging if they are too large and take
too long load all the classes. But this was in a specific use case where we
had restarted karaf after the jars were already deployed, and then
re-hot-deployed the jars.
was (Author: JIRAUSER307601):
We never really pinpointed the source of the problem but found a workaround
that prevents the hangs, at least we haven't seen a hang since implementing
this workaround.
We were including a few dependencies in our service jar that were already
provided by Karaf. In particular, we were including all the the camel libs our
project needed as well as some common-* libs, jakarata-xml, log4j,
fasterxml.jackson, etc. In some cases the versions were the same, others
slightly different versions.
When we synced up all the versions we could with what's provided in karaf 4.4.6
and marked the dependency scopes as provided in our pom, then many were no
longer included in the service jar and it became signficantly smaller and the
hangs stopped happening. We noticed some libs were still being included even
though they were marked as provided and that was because they were transitive
dependencies on other dependencies and the maven plugins still included those.
So we used the exclusion tag in the parent dependency to also prevent those
from being added to our service jar.
So my best guess is there is some risk of jars not re-deploying in karaf if
they have some mix of classes in them already provided in karaf. Or maybe
there is some risk of jars deployments hanging if they are too large and take
too long load all the classes. But this was in a specific use case where we
had restarted karaf after the jars were already deployed, and then
re-hot-deployed the jars.
> Bundles get stuck in Starting status with nothing in logs
> ---------------------------------------------------------
>
> Key: KARAF-7881
> URL: https://issues.apache.org/jira/browse/KARAF-7881
> Project: Karaf
> Issue Type: Question
> Components: karaf
> Affects Versions: 4.4.6
> Environment: Karaf 4.4.6, Camel 4.7.0, Windows
> OpenJDK 64-Bit Server VM Microsoft-10377968 (build 21.0.5+11-LTS, mixed mode,
> sharing)
> Reporter: Darrel Riekhof
> Priority: Major
>
> After initially deploying our model, service, and XML blueprint bundles, all
> is well.
> But after stopping and starting Karaf (as a windows service or stand alone),
> and then rebuilding and redeploying our model and service bundles by
> replacing their jars in the deploy directory we frequently get in a state
> where the service bundle gets stuck in the starting status, and then any
> blueprint we try to hot deploy in same manner also gets stuck in the
> 'Starting'.
> Example:
> 308 │ Active │ 80 │ 1.0.0.SNAPSHOT │ our-model
> 309 │ Starting │ 80 │ 1.0.0.SNAPSHOT │ our-service
> 310 │ Starting │ 80 │ 0.0.0 │ a-blueprint.xml
> admin@root()>
> Once in this state trying to stop the 'our-service' bundle just hangs the
> karaf console, and trying to stop the windows karaf service also hangs and we
> have to kill the karaf java process with task manager or a CLI kill command.
> Nothing is written to any of the logs in data/log. I'm not sure how to debug
> this issue or what to try. The service jar file is kind of large, about
> 15mb, so we were thinking of trying to divide that up in a few bundles. Or,
> I've tried removing some of the compile time dependencies from our services
> jar which look to already be available in karaf, like the camel libraries.
> I've noticed if I mark them as provided in our POM file, then they don't get
> placed in the services jar, but they seem to be required in services jar.
> Any advice appreciated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
