Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <890211358.1239869594856.JavaMail.jira@brutus>
Date: Thu, 16 Apr 2009 01:13:14 -0700 (PDT)
From: "Filippo Diotalevi (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Updated: (FELIX-1036) FileInstaller spawns multiple watchers
 for same directory
In-Reply-To: <1964750923.1239465554912.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/FELIX-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippo Diotalevi updated FELIX-1036:
-------------------------------------

    Attachment: FELIX-1036.patch

Sahoo, can you give this patch a run? I tried againt you use case and in my application, and it seems to work.

First of all I removed the configuration map and ConfigurationKey object.

Second, every time a property file is detected, I (transparently to the user) add a property "felix.fileinstall.filename" with the name of the file as value to the dictionary. In this way the configuration dictionary always contains the filename, and we can just use Configuration Admin service to check if a configuration file has been read and processed.

Finally, when the DirectoryWatcher finds an updated file (or, after Felix startup, simply finds any file) it uses the Configuration Admin service to check if a configuration exist with felix.fileinstall.filename=<filename>
If it already exists, it updates the configuration using the dictionary provided by the configuration file.

The patch assumes that configuration files always "win". In other words, at startup, all cached configurations are updated with dictionaries coming from configuration files.
I think it's acceptable, since when you use FileInstall you are not supposed to change the configurations using other tools like WebConsole.

> FileInstaller spawns multiple watchers for same directory
> ---------------------------------------------------------
>
>                 Key: FELIX-1036
>                 URL: https://issues.apache.org/jira/browse/FELIX-1036
>             Project: Felix
>          Issue Type: Bug
>          Components: File Install
>    Affects Versions: fileinstall-0.9.2
>         Environment: Felix 1.6.0, fileinstall 0.9.2, configadmin 1.0.10
>            Reporter: Sahoo
>         Attachments: FELIX-1036.patch
>
>
> I am running into a strange issue and I don't know if it has to do with any bad use in my part. I am using fileinstall to monitor two directories. fileinstall is configured using config.properties file to monitor a dir called /space/ss141213/software/felix-1.6.0/bundle. I have a cfg file in modules dir that configures fileinstall to monitor a second dir called /tmp/bundles. During subsequent start of the framework, I see fileinstall spwaning more than one watchers for the second dir as shown in the jstack output below:
> "{felix.fileinstall.dir=/space/ss141213/software/felix-1.6.0/bundle, felix.fileinstall.debug=1}" daemon prio=3 tid=0x0833fc00 nid=0xd waiting on condition [0xcbaea000..0xcbaeaae0]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>         at java.lang.Thread.sleep(Native Method)
>         at org.apache.felix.fileinstall.DirectoryWatcher.run(DirectoryWatcher.java:122)
> "{service.pid=org.apache.felix.fileinstall.bd775a2e-9ed9-41e4-8159-83295f3aaefa, felix.fileinstall.dir=/tmp/bundles, service.factorypid=org.apache.felix.fileinstall, felix.fileinstall.debug=1}" daemon prio=3 tid=0x083a5800 nid=0x13 waiting on condition [0xcb7ad000..0xcb7adbe0]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>         at java.lang.Thread.sleep(Native Method)
>         at org.apache.felix.fileinstall.DirectoryWatcher.run(DirectoryWatcher.java:122)
> "{service.pid=org.apache.felix.fileinstall.2aac2209-96d0-4dcb-8e33-ac3f6fbf2856, felix.fileinstall.dir=/tmp/bundles, service.factorypid=org.apache.felix.fileinstall, felix.fileinstall.debug=1}" daemon prio=3 tid=0x08387800 nid=0x12 waiting on condition [0xcb927000..0xcb927a60]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>         at java.lang.Thread.sleep(Native Method)
>         at org.apache.felix.fileinstall.DirectoryWatcher.run(DirectoryWatcher.java:122)
> "{service.pid=org.apache.felix.fileinstall.8997ded4-b1de-46bb-b675-4166734eea73, felix.fileinstall.dir=/tmp/bundles, service.factorypid=org.apache.felix.fileinstall, felix.fileinstall.debug=1}" daemon prio=3 tid=0x0838a000 nid=0x11 waiting on condition [0xcb979000..0xcb9798e0]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>         at java.lang.Thread.sleep(Native Method)
>         at org.apache.felix.fileinstall.DirectoryWatcher.run(DirectoryWatcher.java:122)
> "{service.pid=org.apache.felix.fileinstall.15c95057-a0f9-4269-b827-44df4fa23f6b, felix.fileinstall.dir=/tmp/bundles, service.factorypid=org.apache.felix.fileinstall, felix.fileinstall.debug=1}" daemon prio=3 tid=0x0838c800 nid=0x10 waiting on condition [0xcb9cb000..0xcb9cb960]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>         at java.lang.Thread.sleep(Native Method)
>         at org.apache.felix.fileinstall.DirectoryWatcher.run(DirectoryWatcher.java:122)
> The funny thing is the number keeps increasing by one more for every subsequent restart.
> I see that as part of initial configuration, fileinstall spwans a directory watcher for modules dir, as this is configured using config.properties. Then that directorywatcher spawns a second one after it discovers the cfg file in modules dir. At the same time, configuration manager also notifies fileinstaller based on what appears to be its cached values.
> It is very easy to reproduce. In a standard felix installation, drop fileinstall bundle alonng with configurationmanager bundle into bundle dir. Add it to the auto.start list. Add a cfg file with an entry: felix.fileinstall.dir=/tmp/bundles. Now start Felix. This time you shall see only thread for /tmp/bundles. Restart Felix, now you shall see two threads for that dir. Restart again to see three threads and it continues. If you clean the cache, it goes back to one thread.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.