[
https://issues.apache.org/jira/browse/KARAF-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467145#comment-17467145
]
Robert Schulte edited comment on KARAF-7306 at 12/31/21, 8:33 AM:
------------------------------------------------------------------
It's maybe a race condition. Does it always fail for you ?
It failed every time I tried, yes. I'll attach the output of 'info' below. OS
Windows is probably not the most popular environment ;)
I have compared 4.2.8 and 4.3.3 in the debugger and on my machine, the fact
that {{processingFailures}} get a second chance in 4.2.8 but do not in 4.3.3
(due to FELIX-6490) makes the difference.
But it took me a while to get to this conclusion.. There is definitely a timing
issue (which might very well be caused by a race condition), since imo, the
blueprint artifacts should not make it into the {{processingFailures}} set. But
they always wind up in that set on my machine. This is strange because:
* file-install has start level 12
* blueprint deployer has start level 24 and
* felix.fileinstall.active.level = 80
If this worked correctly, the handler for blueprints should be already
registered before they are considered by file-install. But this is not the case
on my machine! With an attached debugger, I found that the activator of the
blueprint deployer is invoked *after* framework start level is 100 from
file-install's point of view. Before creating this issue, I skimmed through
~200 file-install issues and saw someone else reporting a similiar issue
regarding ordering issues. If I find it again, I'll link it here.
If you are unable to reproduce it, it is very likely that the start level
orchestration works for you. For me it doesn't and it always looks like this:
!processingFailures.png!
with artifacts being trapped in {{processingFailures}} until a file is touched
in /deploy.
{noformat}
karaf@root()> info
Karaf
Karaf version 4.3.3
Karaf home C:\path\apache-karaf-4.3.3
Karaf base C:\path\apache-karaf-4.3.3
OSGi Framework org.apache.felix.framework-6.0.5JVM
Java Virtual Machine OpenJDK 64-Bit Server VM version 11.0.11+9
Version 11.0.11
Vendor AdoptOpenJDK
Pid 15504
Uptime 26.952 seconds
Process CPU time 27.390 seconds
Process CPU load -1.00
System CPU load -1.00
Open file descriptors -1
Max file descriptors -1
Total compile time 20.289 seconds
Threads
Live threads 100
Daemon threads 76
Peak 101
Total started 217
Memory
Current heap size 170,194 kbytes
Maximum heap size 12,380,160 kbytes
Committed heap size 774,144 kbytes
Pending objects 0
Garbage collector Name = 'G1 Young Generation', Collections = 4,
Time = 0.035 seconds
Garbage collector Name = 'G1 Old Generation', Collections = 0, Time
= 0.000 seconds
Classes
Current classes loaded 9,012
Total classes loaded 9,012
Total classes unloaded 0
Operating system
Name Windows 10 version 10.0
Architecture amd64
Processors 16{noformat}
was (Author: robert schulte):
It's maybe a race condition. Does it always fail for you ?
It failed every time I tried, yes. I'll attach the output of 'info' below. OS
Windows is probably not the most popular environment ;)
I have compared 4.2.8 and 4.3.3 in the debugger and on my machine, the fact
that {{processingFailures}} get a second chance in 4.2.8 but do not in 4.3.3
(due to FELIX-6490) makes the difference.
But it took me a while to get to this conclusion.. There is definitely a timing
issue (which might very well be caused by a race condition), since imo, the
blueprint artifacts should not make it into the {{processingFailures}} set. But
they always wind up in that set on my machine. This is strange because:
* file-install has start level 12
* blueprint deployer has start level 24 and
* felix.fileinstall.active.level = 80
If this worked correctly, the handler for blueprints should be already
registered before they are considered by file-install. But this is not the case
on my machine! With an attached debugger, I found that the activator of the
blueprint deployer is invoked *after* framework start level is 100 from
file-install's point of view. Before creating this issue, I skimmed through
~200 file-install issues and saw someone else reporting a similiar issue
regarding ordering issues. If I find it again, I'll link it here.
If you are unable to reproduce it, it is very likely that the start level
orchestration works for you. For me it doesn't and it always looks like this:
!processingFailures.png!
with artifacts being trapped in {{processingFailures}} until a file is touched
in /deploy.
{noformat}
karaf@root()> info
Karaf
Karaf version 4.3.3
Karaf home C:\path\apache-karaf-4.3.3
Karaf base C:\path\apache-karaf-4.3.3
OSGi Framework org.apache.felix.framework-6.0.5JVM
Java Virtual Machine OpenJDK 64-Bit Server VM version 11.0.11+9
Version 11.0.11
Vendor AdoptOpenJDK
Pid 15504
Uptime 26.952 seconds
Process CPU time 27.390 seconds
Process CPU load -1.00
System CPU load -1.00
Open file descriptors -1
Max file descriptors -1
Total compile time 20.289 seconds
Threads
Live threads 100
Daemon threads 76
Peak 101
Total started 217
Memory
Current heap size 170,194 kbytes
Maximum heap size 12,380,160 kbytes
Committed heap size 774,144 kbytes
Pending objects 0
Garbage collector Name = 'G1 Young Generation', Collections = 4,
Time = 0.035 seconds
Garbage collector Name = 'G1 Old Generation', Collections = 0, Time
= 0.000 seconds
Classes
Current classes loaded 9,012
Total classes loaded 9,012
Total classes unloaded 0
Operating system
Name Windows 10 version 10.0
Architecture amd64
Processors 16{noformat}
> Hot deployment (deploy directory) does not work for provisioned blueprints
> --------------------------------------------------------------------------
>
> Key: KARAF-7306
> URL: https://issues.apache.org/jira/browse/KARAF-7306
> Project: Karaf
> Issue Type: Bug
> Components: karaf
> Affects Versions: 4.3.3
> Reporter: Robert Schulte
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Attachments: client.xml, org.apache.karaf.features.cfg,
> processingFailures.png
>
>
> h2. Context
> I tried to migrate a custom Karaf distribution from 4.2.8 to 4.3.3
> (fileinstall version 3.6.4 -> 3.7.0). The distribution contains a blueprint
> (xml) file that is supposed to be handled by one of Karaf's custom
> ArtifactListener_s. This kind of deploment works for Karaf 4.2.8 but fails
> for 4.3.3.
> h2. Steps to Reproduce
> On a vanilla Karaf 4.3.3
> * place [^org.apache.karaf.features.cfg] in *etc* directory (adds
> aries-blueprint to boot features)
> * place [^client.xml] in *deploy* directory (this is copied from
> examples/karaf-blueprint-example-client)
> * do a clean start of karaf
> * on Karaf shell, execute {{bundle:list | grep "client.xml"}}
> h2. Actual Results
> No matching bundles are listed
> Addendum: if a file in deploy is touched while Karaf is running, the
> blueprint gets deployed. This does not need to be client.xml itself, renaming
> deploy/README to deploy/README.txt also results in the blueprint getting
> deployed
> h2. Expected Results
> {noformat}
> karaf@root()> bundle:list | grep "client.xml"
> 70 | Installed | 80 | 0.0.0 | client.xml
> {noformat}
> The XML file from deploy directory should be listed. Note: The bundle cannot
> start since it is missing requirements
> h2. Cause
> Karaf updated its dependency on Apache Felix File Install. That project has
> introduced a regression (FELIX-6490, which I also reported) that breaks the
> hot deployment for files that require custom handlers (like blueprint)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
