[sip-comm-dev] FileNotFoundException with revision.location in Felix


#1

Hi Folks,

I am a newbie to sip communicator. I am trying to build and run
sip-communicator in my local machine(windows 7).

I faced a couple of issues,

   - In Eclipse, there were compilation errors pertaining to "neomedia.jar".
   Hence, I added the jar from "../sc-modules/os-specific/windows/neomedia.jar"
   whereas all other references were pointing to the jar's in lib directory. Is
   this the right way? Or just a temporary tweak?
   - Secondly, when I run the sip-communicator, I get the following
   exception

          java.io.FileNotFoundException: C:\Users\....\AppData\Roaming\SIP
Communicator\sip-communicator.bin\bundle11\version0.-1\revision.location
(The system cannot find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at
org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:436)
at
org.apache.felix.framework.cache.BundleArchive.getRevisionLocation(BundleArchive.java:706)
at
org.apache.felix.framework.cache.BundleArchive.<init>(BundleArchive.java:206)
at
org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.java:141)
at org.apache.felix.framework.Felix.init(Felix.java:600)
at org.apache.felix.main.Main.main(Main.java:292)
at
net.java.sip.communicator.launcher.SIPCommunicator.main(SIPCommunicator.java:122)
IOException in readRegistry: java.io.EOFException

    This exception does not stop running the application though. I tried
using the latest felix version which did not help. I just wanted to know how
to overcome this issue.

Thanks a bunch for your time.

Cheers,
Gokul


#2

Hi Folks,

I am a newbie to sip communicator. I am trying to build and run sip-communicator in my local machine(windows 7).

I faced a couple of issues,

    * In Eclipse, there were compilation errors pertaining to
      "neomedia.jar". Hence, I added the jar from
      "../sc-modules/os-specific/windows/neomedia.jar" whereas all
      other references were pointing to the jar's in lib directory. Is
      this the right way? Or just a temporary tweak?
    * Secondly, when I run the sip-communicator, I get the following
      exception

java.io.FileNotFoundException: C:\Users\....\AppData\Roaming\SIP Communicator\sip-communicator.bin\bundle11\version0.-1\revision.location (The system cannot find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:436)
at org.apache.felix.framework.cache.BundleArchive.getRevisionLocation(BundleArchive.java:706)
at org.apache.felix.framework.cache.BundleArchive.<init>(BundleArchive.java:206)
at org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.java:141)
at org.apache.felix.framework.Felix.init(Felix.java:600)
at org.apache.felix.main.Main.main(Main.java:292)
at net.java.sip.communicator.launcher.SIPCommunicator.main(SIPCommunicator.java:122)
IOException in readRegistry: java.io.EOFException

    This exception does not stop running the application though. I tried using the latest felix version which did not help. I just wanted to know how to overcome this issue.

This is usually a result of a corrupted framework cache...not sure how it gets corrupt, though, we've never been able to track it down.

Try deleting the bundle cache and restarting.

-> richard

···

On 3/9/10 12:25, Gokul Jeyapaul wrote:

Thanks a bunch for your time.

Cheers,
Gokul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

In Eclipse, there were compilation errors pertaining to "neomedia.jar".
Hence, I added the jar from "../sc-modules/os-specific/windows/neomedia.jar"
whereas all other references were pointing to the jar's in lib directory. Is
this the right way? Or just a temporary tweak?

Setting up SIP Communicator for development using Eclipse is as simple
as http://www.sip-communicator.org/index.php/Documentation/ConfigureEclipseNew#toc3
and does not require undocumented treaking.

Secondly, when I run the sip-communicator, I get the following exception

      java\.io\.FileNotFoundException: C:\\Users\\\.\.\.\.\\AppData\\Roaming\\SIP

Communicator\sip-communicator.bin\bundle11\version0.-1\revision.location
(The system cannot find the path specified)

As Richard said, delete ~/.sip-communicator/sip-communicator.bin on
Linux or ~/Library/Application Support/SIP
Communicator/sip-communicator.bin on Mac OS X or %APPDATA%\SIP
Communicator\sip-communicator.bin on Windows.

···

On Tue, Mar 9, 2010 at 7:25 PM, Gokul Jeyapaul <gokul.jeyapaul@googlemail.com> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Richard, folks,

Richard S. Hall написа:

This is usually a result of a corrupted framework cache...not sure how
it gets corrupt, though, we've never been able to track it down.

I've tried to look into this a bit more and while it still isn't clear
to me exactly why this happens, I believe I've narrowed it down a little
bit.

The FileNotFoundException seems to always be caused by our updatechecker
plugin. The peculiar thing about that plugin is that it doesn't ship in
all of our binaries. Mac's DMG for example doesn't have it because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hey Richard, folks,

Richard S. Hall написа:
   

This is usually a result of a corrupted framework cache...not sure how
it gets corrupt, though, we've never been able to track it down.
     

I've tried to look into this a bit more and while it still isn't clear
to me exactly why this happens, I believe I've narrowed it down a little
bit.

The FileNotFoundException seems to always be caused by our updatechecker
plugin. The peculiar thing about that plugin is that it doesn't ship in
all of our binaries. Mac's DMG for example doesn't have it because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from sources felix
doesn't like the previous bundle and makes a new installation.
   
Well, if you can give me the precise set of steps to reproduce the issue, I will look into it.

-> richard

···

On 3/10/10 6:49, Emil Ivov wrote:

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

How do I go about creating the DMG file for the SC release? I am going to try to debug this issue, so I need to create an updated DMG with a new version of Felix.

Thanks.

-> richard

···

On 3/10/10 19:49, Emil Ivov wrote:

Hey Richard, folks,

Richard S. Hall написа:
   

This is usually a result of a corrupted framework cache...not sure how
it gets corrupt, though, we've never been able to track it down.
     

I've tried to look into this a bit more and while it still isn't clear
to me exactly why this happens, I believe I've narrowed it down a little
bit.

The FileNotFoundException seems to always be caused by our updatechecker
plugin. The peculiar thing about that plugin is that it doesn't ship in
all of our binaries. Mac's DMG for example doesn't have it because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Richard S. Hall написа:

···

On 3/10/10 6:49, Emil Ivov wrote:

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

Well, if you can give me the precise set of steps to reproduce the
issue, I will look into it.

Well actually that was it: 1. Run SC from sources (using ant run), 2.
Run from the DMG, 3. Run from sources again.

Or did you mean something else?

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

How do I go about creating the DMG file for the SC release? I am going to try to debug this issue, so I need to create an updated DMG with a new version of Felix.

I figured it out. Seems like the docs could be improved here slightly...actually, the macosx page appears to be missing.

-> richard

···

On 3/22/10 12:47, Richard S. Hall wrote:

Thanks.

-> richard

On 3/10/10 19:49, Emil Ivov wrote:

Hey Richard, folks,

Richard S. Hall написа:

This is usually a result of a corrupted framework cache...not sure how
it gets corrupt, though, we've never been able to track it down.

I've tried to look into this a bit more and while it still isn't clear
to me exactly why this happens, I believe I've narrowed it down a little
bit.

The FileNotFoundException seems to always be caused by our updatechecker
plugin. The peculiar thing about that plugin is that it doesn't ship in
all of our binaries. Mac's DMG for example doesn't have it because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Ok, I see what is going on here. If, in a subsequent run, a bundle installed by reference is not found, then this results in the revision directory in the bundle cache getting deleted for that bundle. Unfortunately, this leaves the bundle directory for that bundle in the bundle cache (i.e., we have a bundle directory in the cache without a bundle revision directory). This should never be the case.

I think what we need to do in Felix is make sure that such an error bubbles up far enough to delete the bundle directory. For a first-time install of a bundle, it would result in the bundle directory being deleted, but for re-installs it only results in the bundle revision directory being installed.

Not sure if this is the root of all bundle cache corruptions, but it at least explains this scenario. I will look into a fix.

-> richard

···

On 3/22/10 14:58, Richard S. Hall wrote:

On 3/22/10 12:47, Richard S. Hall wrote:

How do I go about creating the DMG file for the SC release? I am going to try to debug this issue, so I need to create an updated DMG with a new version of Felix.

I figured it out. Seems like the docs could be improved here slightly...actually, the macosx page appears to be missing.

-> richard

Thanks.

-> richard

On 3/10/10 19:49, Emil Ivov wrote:

Hey Richard, folks,

Richard S. Hall написа:

This is usually a result of a corrupted framework cache...not sure how
it gets corrupt, though, we've never been able to track it down.

I've tried to look into this a bit more and while it still isn't clear
to me exactly why this happens, I believe I've narrowed it down a little
bit.

The FileNotFoundException seems to always be caused by our updatechecker
plugin. The peculiar thing about that plugin is that it doesn't ship in
all of our binaries. Mac's DMG for example doesn't have it because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Ok, I see what is going on here. If, in a subsequent run, a bundle installed by reference is not found, then this results in the revision directory in the bundle cache getting deleted for that bundle. Unfortunately, this leaves the bundle directory for that bundle in the bundle cache (i.e., we have a bundle directory in the cache without a bundle revision directory). This should never be the case.

I think what we need to do in Felix is make sure that such an error bubbles up far enough to delete the bundle directory. For a first-time install of a bundle, it would result in the bundle directory being deleted, but for re-installs it only results in the bundle revision directory being installed.

Not sure if this is the root of all bundle cache corruptions, but it at least explains this scenario. I will look into a fix.

In Felix trunk, I have committed a fix to delete the entire cached bundle directory when it fails to reload from the cache. It is not clear if this is the best policy 100% of the time, but it seems to be correct most of the time and certainly fixes this particular scenario since the updater bundle will just get re-cached when you go back and run it from the source build.

Currently, Felix trunk is for version 3.0, but we might do a 2.0.5 release before then and include this fix, then SC can use that version instead of 2.0.2...at least until 3.0 comes out! :slight_smile:

-> richard

···

On 3/22/10 15:42, Richard S. Hall wrote:

-> richard

On 3/22/10 14:58, Richard S. Hall wrote:

On 3/22/10 12:47, Richard S. Hall wrote:

How do I go about creating the DMG file for the SC release? I am going to try to debug this issue, so I need to create an updated DMG with a new version of Felix.

I figured it out. Seems like the docs could be improved here slightly...actually, the macosx page appears to be missing.

-> richard

Thanks.

-> richard

On 3/10/10 19:49, Emil Ivov wrote:

Hey Richard, folks,

Richard S. Hall написа:

This is usually a result of a corrupted framework cache...not sure how
it gets corrupt, though, we've never been able to track it down.

I've tried to look into this a bit more and while it still isn't clear
to me exactly why this happens, I believe I've narrowed it down a little
bit.

The FileNotFoundException seems to always be caused by our updatechecker
plugin. The peculiar thing about that plugin is that it doesn't ship in
all of our binaries. Mac's DMG for example doesn't have it because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Just an update, I've started preparing for the 2.0.5 release of the Felix framework which has a fix for the bundle cache corruption for the scenario described in this thread...I am not sure if this is the root of all such errors, but at least it is a good start to fixing it.

Hopefully 2.0.5 will be released next week...I'll follow up to make sure SC is updated to the new version.

-> richard

···

On 3/23/10 2:01, Richard S. Hall wrote:

On 3/22/10 15:42, Richard S. Hall wrote:

Ok, I see what is going on here. If, in a subsequent run, a bundle installed by reference is not found, then this results in the revision directory in the bundle cache getting deleted for that bundle. Unfortunately, this leaves the bundle directory for that bundle in the bundle cache (i.e., we have a bundle directory in the cache without a bundle revision directory). This should never be the case.

I think what we need to do in Felix is make sure that such an error bubbles up far enough to delete the bundle directory. For a first-time install of a bundle, it would result in the bundle directory being deleted, but for re-installs it only results in the bundle revision directory being installed.

Not sure if this is the root of all bundle cache corruptions, but it at least explains this scenario. I will look into a fix.

In Felix trunk, I have committed a fix to delete the entire cached bundle directory when it fails to reload from the cache. It is not clear if this is the best policy 100% of the time, but it seems to be correct most of the time and certainly fixes this particular scenario since the updater bundle will just get re-cached when you go back and run it from the source build.

Currently, Felix trunk is for version 3.0, but we might do a 2.0.5 release before then and include this fix, then SC can use that version instead of 2.0.2...at least until 3.0 comes out! :slight_smile:

-> richard

-> richard

On 3/22/10 14:58, Richard S. Hall wrote:

On 3/22/10 12:47, Richard S. Hall wrote:

How do I go about creating the DMG file for the SC release? I am going to try to debug this issue, so I need to create an updated DMG with a new version of Felix.

I figured it out. Seems like the docs could be improved here slightly...actually, the macosx page appears to be missing.

-> richard

Thanks.

-> richard

On 3/10/10 19:49, Emil Ivov wrote:

Hey Richard, folks,

Richard S. Hall написа:

This is usually a result of a corrupted framework cache...not sure how
it gets corrupt, though, we've never been able to track it down.

I've tried to look into this a bit more and while it still isn't clear
to me exactly why this happens, I believe I've narrowed it down a little
bit.

The FileNotFoundException seems to always be caused by our updatechecker
plugin. The peculiar thing about that plugin is that it doesn't ship in
all of our binaries. Mac's DMG for example doesn't have it because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Felix 2.0.5 was released, which should help with the cache corruption issue described in this thread...so feel free to upgrade. Thanks.

-> richard

···

On 4/1/10 9:14, Richard S. Hall wrote:

Just an update, I've started preparing for the 2.0.5 release of the Felix framework which has a fix for the bundle cache corruption for the scenario described in this thread...I am not sure if this is the root of all such errors, but at least it is a good start to fixing it.

Hopefully 2.0.5 will be released next week...I'll follow up to make sure SC is updated to the new version.

-> richard

On 3/23/10 2:01, Richard S. Hall wrote:

On 3/22/10 15:42, Richard S. Hall wrote:

Ok, I see what is going on here. If, in a subsequent run, a bundle installed by reference is not found, then this results in the revision directory in the bundle cache getting deleted for that bundle. Unfortunately, this leaves the bundle directory for that bundle in the bundle cache (i.e., we have a bundle directory in the cache without a bundle revision directory). This should never be the case.

I think what we need to do in Felix is make sure that such an error bubbles up far enough to delete the bundle directory. For a first-time install of a bundle, it would result in the bundle directory being deleted, but for re-installs it only results in the bundle revision directory being installed.

Not sure if this is the root of all bundle cache corruptions, but it at least explains this scenario. I will look into a fix.

In Felix trunk, I have committed a fix to delete the entire cached bundle directory when it fails to reload from the cache. It is not clear if this is the best policy 100% of the time, but it seems to be correct most of the time and certainly fixes this particular scenario since the updater bundle will just get re-cached when you go back and run it from the source build.

Currently, Felix trunk is for version 3.0, but we might do a 2.0.5 release before then and include this fix, then SC can use that version instead of 2.0.2...at least until 3.0 comes out! :slight_smile:

-> richard

-> richard

On 3/22/10 14:58, Richard S. Hall wrote:

On 3/22/10 12:47, Richard S. Hall wrote:

How do I go about creating the DMG file for the SC release? I am going to try to debug this issue, so I need to create an updated DMG with a new version of Felix.

I figured it out. Seems like the docs could be improved here slightly...actually, the macosx page appears to be missing.

-> richard

Thanks.

-> richard

On 3/10/10 19:49, Emil Ivov wrote:

Hey Richard, folks,

Richard S. Hall написа:

This is usually a result of a corrupted framework cache...not sure how
it gets corrupt, though, we've never been able to track it down.

I've tried to look into this a bit more and while it still isn't clear
to me exactly why this happens, I believe I've narrowed it down a little
bit.

The FileNotFoundException seems to always be caused by our updatechecker
plugin. The peculiar thing about that plugin is that it doesn't ship in
all of our binaries. Mac's DMG for example doesn't have it because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Just tried it and it does fix the problem. 2.0.5 is now on SVN (r7015)
and should be available with build.2565

Thanks for fixing this Richard!

Cheers,
Emil

P.S. Note that you will get the FNF exceptions one last time before
felix deletes them. Everything will be fine next time you restart.

На 16.04.10 18:32, Richard S. Hall написа:

···

Felix 2.0.5 was released, which should help with the cache corruption
issue described in this thread...so feel free to upgrade. Thanks.

-> richard

On 4/1/10 9:14, Richard S. Hall wrote:

Just an update, I've started preparing for the 2.0.5 release of the
Felix framework which has a fix for the bundle cache corruption for
the scenario described in this thread...I am not sure if this is the
root of all such errors, but at least it is a good start to fixing it.

Hopefully 2.0.5 will be released next week...I'll follow up to make
sure SC is updated to the new version.

-> richard

On 3/23/10 2:01, Richard S. Hall wrote:

On 3/22/10 15:42, Richard S. Hall wrote:

Ok, I see what is going on here. If, in a subsequent run, a bundle
installed by reference is not found, then this results in the
revision directory in the bundle cache getting deleted for that
bundle. Unfortunately, this leaves the bundle directory for that
bundle in the bundle cache (i.e., we have a bundle directory in the
cache without a bundle revision directory). This should never be the
case.

I think what we need to do in Felix is make sure that such an error
bubbles up far enough to delete the bundle directory. For a
first-time install of a bundle, it would result in the bundle
directory being deleted, but for re-installs it only results in the
bundle revision directory being installed.

Not sure if this is the root of all bundle cache corruptions, but it
at least explains this scenario. I will look into a fix.

In Felix trunk, I have committed a fix to delete the entire cached
bundle directory when it fails to reload from the cache. It is not
clear if this is the best policy 100% of the time, but it seems to be
correct most of the time and certainly fixes this particular scenario
since the updater bundle will just get re-cached when you go back and
run it from the source build.

Currently, Felix trunk is for version 3.0, but we might do a 2.0.5
release before then and include this fix, then SC can use that
version instead of 2.0.2...at least until 3.0 comes out! :slight_smile:

-> richard

-> richard

On 3/22/10 14:58, Richard S. Hall wrote:

On 3/22/10 12:47, Richard S. Hall wrote:

How do I go about creating the DMG file for the SC release? I am
going to try to debug this issue, so I need to create an updated
DMG with a new version of Felix.

I figured it out. Seems like the docs could be improved here
slightly...actually, the macosx page appears to be missing.

-> richard

Thanks.

-> richard

On 3/10/10 19:49, Emil Ivov wrote:

Hey Richard, folks,

Richard S. Hall написа:

This is usually a result of a corrupted framework cache...not
sure how
it gets corrupt, though, we've never been able to track it down.

I've tried to look into this a bit more and while it still isn't
clear
to me exactly why this happens, I believe I've narrowed it down a
little
bit.

The FileNotFoundException seems to always be caused by our
updatechecker
plugin. The peculiar thing about that plugin is that it doesn't
ship in
all of our binaries. Mac's DMG for example doesn't have it
because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as
bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from
sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------

To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

Just tried it and it does fix the problem. 2.0.5 is now on SVN (r7015)
and should be available with build.2565

Thanks for fixing this Richard!
   
Great! No problem.

-> richard

···

On 4/19/10 9:50, Emil Ivov wrote:

Cheers,
Emil

P.S. Note that you will get the FNF exceptions one last time before
felix deletes them. Everything will be fine next time you restart.

На 16.04.10 18:32, Richard S. Hall написа:
   

Felix 2.0.5 was released, which should help with the cache corruption
issue described in this thread...so feel free to upgrade. Thanks.

-> richard

On 4/1/10 9:14, Richard S. Hall wrote:
     

Just an update, I've started preparing for the 2.0.5 release of the
Felix framework which has a fix for the bundle cache corruption for
the scenario described in this thread...I am not sure if this is the
root of all such errors, but at least it is a good start to fixing it.

Hopefully 2.0.5 will be released next week...I'll follow up to make
sure SC is updated to the new version.

-> richard

On 3/23/10 2:01, Richard S. Hall wrote:
       

On 3/22/10 15:42, Richard S. Hall wrote:
         

Ok, I see what is going on here. If, in a subsequent run, a bundle
installed by reference is not found, then this results in the
revision directory in the bundle cache getting deleted for that
bundle. Unfortunately, this leaves the bundle directory for that
bundle in the bundle cache (i.e., we have a bundle directory in the
cache without a bundle revision directory). This should never be the
case.

I think what we need to do in Felix is make sure that such an error
bubbles up far enough to delete the bundle directory. For a
first-time install of a bundle, it would result in the bundle
directory being deleted, but for re-installs it only results in the
bundle revision directory being installed.

Not sure if this is the root of all bundle cache corruptions, but it
at least explains this scenario. I will look into a fix.
           

In Felix trunk, I have committed a fix to delete the entire cached
bundle directory when it fails to reload from the cache. It is not
clear if this is the best policy 100% of the time, but it seems to be
correct most of the time and certainly fixes this particular scenario
since the updater bundle will just get re-cached when you go back and
run it from the source build.

Currently, Felix trunk is for version 3.0, but we might do a 2.0.5
release before then and include this fix, then SC can use that
version instead of 2.0.2...at least until 3.0 comes out! :slight_smile:

-> richard

-> richard

On 3/22/10 14:58, Richard S. Hall wrote:
           

On 3/22/10 12:47, Richard S. Hall wrote:
             

How do I go about creating the DMG file for the SC release? I am
going to try to debug this issue, so I need to create an updated
DMG with a new version of Felix.
               

I figured it out. Seems like the docs could be improved here
slightly...actually, the macosx page appears to be missing.

-> richard

Thanks.

-> richard

On 3/10/10 19:49, Emil Ivov wrote:
               

Hey Richard, folks,

Richard S. Hall написа:
                 

This is usually a result of a corrupted framework cache...not
sure how
it gets corrupt, though, we've never been able to track it down.
                   

I've tried to look into this a bit more and while it still isn't
clear
to me exactly why this happens, I believe I've narrowed it down a
little
bit.

The FileNotFoundException seems to always be caused by our
updatechecker
plugin. The peculiar thing about that plugin is that it doesn't
ship in
all of our binaries. Mac's DMG for example doesn't have it
because it
updates via sparkle.

So here's what happens.

1. I run SC from sources and it installs the updatechecker plugin as
bundle57.

2. I then run SC from my DMG installation whose
felix.client.run.properties file does not include the reference to
updatechecker.jar. So far so good, however,

3. the next time I run SC from sources (without any changes on the
sandbox since step 1.) it reinstalls the updatechecker as
bundle80 and
then throws the file not found exception about bundle57.

It's as if running SC from the DMG somehow messes up the previous
installation of the updatechecker so next time we run from
sources felix
doesn't like the previous bundle and makes a new installation.

As I said, I don't really know why this happens yet, but thought I'd
share my experience in case it rings any bells.

Cheers,
Emil

---------------------------------------------------------------------

To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net