You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2010/10/08 22:46:32 UTC
[jira] Created: (FELIX-2646) [Framework] Locking could be used to
prevent concurrent access to a single bundle cache
[Framework] Locking could be used to prevent concurrent access to a single bundle cache
---------------------------------------------------------------------------------------
Key: FELIX-2646
URL: https://issues.apache.org/jira/browse/FELIX-2646
Project: Felix
Issue Type: New Feature
Components: Framework
Affects Versions: framework-3.0.4
Reporter: Richard S. Hall
Priority: Minor
Fix For: framework-3.2.0
Currently, the framework completely ignores concurrent access to the same bundle cache and leaves it as a configuration issue. The downside of this approach is that a mistaken configuration could corrupt your bundle cache. We could avoid this by introducing some sort of bundle cache locking protocol using java.nio.channels.FileLock. I think it would be sufficient to simply implement a fail-fast locking protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2646) [Framework] Locking could be used to
prevent concurrent access to a single bundle cache
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-2646:
-----------------------------------
Attachment: FELIX-2646.txt
Here is a proposed patch for bundle cache locking. I did a simple test by starting the framework twice from the same directory and it appears to work. The main downside of adding locking is it adds one more open file per framework instance. What do people think, is this a worthy addition?
> [Framework] Locking could be used to prevent concurrent access to a single bundle cache
> ---------------------------------------------------------------------------------------
>
> Key: FELIX-2646
> URL: https://issues.apache.org/jira/browse/FELIX-2646
> Project: Felix
> Issue Type: New Feature
> Components: Framework
> Affects Versions: framework-3.0.4
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2646.txt
>
>
> Currently, the framework completely ignores concurrent access to the same bundle cache and leaves it as a configuration issue. The downside of this approach is that a mistaken configuration could corrupt your bundle cache. We could avoid this by introducing some sort of bundle cache locking protocol using java.nio.channels.FileLock. I think it would be sufficient to simply implement a fail-fast locking protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2646) [Framework] Locking could be used to
prevent concurrent access to a single bundle cache
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925768#action_12925768 ]
Karl Pauls commented on FELIX-2646:
-----------------------------------
It should be no problem for android as that is 1.5 and has support for the nio packages. However, I agree that it might be a problem for embedded users running on 1.3 but that is getting pretty rare plus I don't think we really support 1.3 anymore anyways.
> [Framework] Locking could be used to prevent concurrent access to a single bundle cache
> ---------------------------------------------------------------------------------------
>
> Key: FELIX-2646
> URL: https://issues.apache.org/jira/browse/FELIX-2646
> Project: Felix
> Issue Type: New Feature
> Components: Framework
> Affects Versions: framework-3.0.4
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2646.txt
>
>
> Currently, the framework completely ignores concurrent access to the same bundle cache and leaves it as a configuration issue. The downside of this approach is that a mistaken configuration could corrupt your bundle cache. We could avoid this by introducing some sort of bundle cache locking protocol using java.nio.channels.FileLock. I think it would be sufficient to simply implement a fail-fast locking protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2646) [Framework] Locking could be used to
prevent concurrent access to a single bundle cache
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925544#action_12925544 ]
Karl Pauls commented on FELIX-2646:
-----------------------------------
I think this makes sense and the patch looks good.
> [Framework] Locking could be used to prevent concurrent access to a single bundle cache
> ---------------------------------------------------------------------------------------
>
> Key: FELIX-2646
> URL: https://issues.apache.org/jira/browse/FELIX-2646
> Project: Felix
> Issue Type: New Feature
> Components: Framework
> Affects Versions: framework-3.0.4
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2646.txt
>
>
> Currently, the framework completely ignores concurrent access to the same bundle cache and leaves it as a configuration issue. The downside of this approach is that a mistaken configuration could corrupt your bundle cache. We could avoid this by introducing some sort of bundle cache locking protocol using java.nio.channels.FileLock. I think it would be sufficient to simply implement a fail-fast locking protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2646) [Framework] Locking could be used to
prevent concurrent access to a single bundle cache
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925795#action_12925795 ]
Richard S. Hall commented on FELIX-2646:
----------------------------------------
I suppose if it ends up posing such an issue, we could always make it configurable so that portion of code need not be executed in a 1.3 environment. But I'd rather not make it configurable in advance to avoid unnecessary configuration options.
> [Framework] Locking could be used to prevent concurrent access to a single bundle cache
> ---------------------------------------------------------------------------------------
>
> Key: FELIX-2646
> URL: https://issues.apache.org/jira/browse/FELIX-2646
> Project: Felix
> Issue Type: New Feature
> Components: Framework
> Affects Versions: framework-3.0.4
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2646.txt
>
>
> Currently, the framework completely ignores concurrent access to the same bundle cache and leaves it as a configuration issue. The downside of this approach is that a mistaken configuration could corrupt your bundle cache. We could avoid this by introducing some sort of bundle cache locking protocol using java.nio.channels.FileLock. I think it would be sufficient to simply implement a fail-fast locking protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-2646) [Framework] Locking could be used to
prevent concurrent access to a single bundle cache
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall closed FELIX-2646.
----------------------------------
Resolution: Fixed
Fix Version/s: (was: framework-3.2.0)
framework-3.0.6
Assignee: Richard S. Hall
Committed patch.
> [Framework] Locking could be used to prevent concurrent access to a single bundle cache
> ---------------------------------------------------------------------------------------
>
> Key: FELIX-2646
> URL: https://issues.apache.org/jira/browse/FELIX-2646
> Project: Felix
> Issue Type: New Feature
> Components: Framework
> Affects Versions: framework-3.0.4
> Reporter: Richard S. Hall
> Assignee: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.0.6
>
> Attachments: FELIX-2646.txt
>
>
> Currently, the framework completely ignores concurrent access to the same bundle cache and leaves it as a configuration issue. The downside of this approach is that a mistaken configuration could corrupt your bundle cache. We could avoid this by introducing some sort of bundle cache locking protocol using java.nio.channels.FileLock. I think it would be sufficient to simply implement a fail-fast locking protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2646) [Framework] Locking could be used to
prevent concurrent access to a single bundle cache
Posted by "Sahoo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925552#action_12925552 ]
Sahoo commented on FELIX-2646:
------------------------------
Thanks for making this enhancement.
> [Framework] Locking could be used to prevent concurrent access to a single bundle cache
> ---------------------------------------------------------------------------------------
>
> Key: FELIX-2646
> URL: https://issues.apache.org/jira/browse/FELIX-2646
> Project: Felix
> Issue Type: New Feature
> Components: Framework
> Affects Versions: framework-3.0.4
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2646.txt
>
>
> Currently, the framework completely ignores concurrent access to the same bundle cache and leaves it as a configuration issue. The downside of this approach is that a mistaken configuration could corrupt your bundle cache. We could avoid this by introducing some sort of bundle cache locking protocol using java.nio.channels.FileLock. I think it would be sufficient to simply implement a fail-fast locking protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2646) [Framework] Locking could be used to
prevent concurrent access to a single bundle cache
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925766#action_12925766 ]
Felix Meschberger commented on FELIX-2646:
------------------------------------------
Makes sense and looks good.
The only drawback is, that it requires Java 1.4 or better -- but to me this presents absolutely no problem. But cannot tell about embedded uses (Android comes to mind).
> [Framework] Locking could be used to prevent concurrent access to a single bundle cache
> ---------------------------------------------------------------------------------------
>
> Key: FELIX-2646
> URL: https://issues.apache.org/jira/browse/FELIX-2646
> Project: Felix
> Issue Type: New Feature
> Components: Framework
> Affects Versions: framework-3.0.4
> Reporter: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.2.0
>
> Attachments: FELIX-2646.txt
>
>
> Currently, the framework completely ignores concurrent access to the same bundle cache and leaves it as a configuration issue. The downside of this approach is that a mistaken configuration could corrupt your bundle cache. We could avoid this by introducing some sort of bundle cache locking protocol using java.nio.channels.FileLock. I think it would be sufficient to simply implement a fail-fast locking protocol.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.