You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Sahoo (JIRA)" <ji...@apache.org> on 2012/10/16 15:47:03 UTC
[jira] [Created] (FELIX-3713) Bundle.start() returns without
starting the bundle
Sahoo created FELIX-3713:
----------------------------
Summary: Bundle.start() returns without starting the bundle
Key: FELIX-3713
URL: https://issues.apache.org/jira/browse/FELIX-3713
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.0.2
Reporter: Sahoo
See email exchange between Sahoo & Richard that happened in dev alias on 16th Oct 2012 for issue details:
> While investigating some issues in GlassFish, what we are seeing is that even if our code is calling bundle.start(START_TRANSIENT), the bundle is not getting started immediately, nor is the code blocking. It simply returns without Bundle's activator getting called and bundle.getState() == RESOLVED. We see this happening when there is a start level change in progress. We are currently using Felix 4.0.2. Looking at the code, I see this to be by design, but isn't it a non-compliant behavior? Should bundle.start() not wait until the bundle is started?
The spec has always been a little lenient about how start levels are processed to give leeway to the frameworks. For us, we viewed this as somewhat of a race condition between threads starting bundles and the start level thread.
However, in the transient case, I wouldn't expect it to remain in RESOLVED state. If its start level wasn't met, it should have thrown an exception. Yet there is a chance in the transient case that it could start asynchronously...not sure if this would really be problematic for you or not...
But it shouldn't remain in the RESOLVED state. Looking at the code, I think there is a bug in this scenario where a transient bundle that is handled asynchronously will not actually end up getting started since the start level thread checks the persistent state of the bundle, which is not set for transient bundles.
You could definitely open up a bug for this last issue...
-> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3713) Bundle.start() returns without
starting the bundle
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507110#comment-13507110 ]
Richard S. Hall commented on FELIX-3713:
----------------------------------------
I'm not sure I see a great solution for this one. One possibility is to somehow pass along the fact in the tuple that this bundle is being transiently started as opposes to being a bundle that is persistently stopped. This still treats the bundle asynchronously and potentially is somewhat complicated since we'd somehow need to mark the bundle as STARTING so that it couldn't be stopped before it was started.
Another approach is to treat transient bundles differently and directly activate them if their start level is met (or fail if it is not). The downside of this approach is that they may activate slightly out of order since it could not be coordinated with the start level thread's active start level.
I think the latter approach is probably the better of the two.
> Bundle.start() returns without starting the bundle
> --------------------------------------------------
>
> Key: FELIX-3713
> URL: https://issues.apache.org/jira/browse/FELIX-3713
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.0.2
> Reporter: Sahoo
> Fix For: framework-4.2.0
>
>
> See email exchange between Sahoo & Richard that happened in dev alias on 16th Oct 2012 for issue details:
> > While investigating some issues in GlassFish, what we are seeing is that even if our code is calling bundle.start(START_TRANSIENT), the bundle is not getting started immediately, nor is the code blocking. It simply returns without Bundle's activator getting called and bundle.getState() == RESOLVED. We see this happening when there is a start level change in progress. We are currently using Felix 4.0.2. Looking at the code, I see this to be by design, but isn't it a non-compliant behavior? Should bundle.start() not wait until the bundle is started?
> The spec has always been a little lenient about how start levels are processed to give leeway to the frameworks. For us, we viewed this as somewhat of a race condition between threads starting bundles and the start level thread.
> However, in the transient case, I wouldn't expect it to remain in RESOLVED state. If its start level wasn't met, it should have thrown an exception. Yet there is a chance in the transient case that it could start asynchronously...not sure if this would really be problematic for you or not...
> But it shouldn't remain in the RESOLVED state. Looking at the code, I think there is a bug in this scenario where a transient bundle that is handled asynchronously will not actually end up getting started since the start level thread checks the persistent state of the bundle, which is not set for transient bundles.
> You could definitely open up a bug for this last issue...
> -> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3713) Bundle.start() returns without
starting the bundle
Posted by "TangYong (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510304#comment-13510304 ]
TangYong commented on FELIX-3713:
---------------------------------
Thanks richard's suggestions very much.
I have a solution for this problem:
The problem happened on the following codes(felix.java Line : 1820, and I used felix 4.0.2):
if (!Thread.currentThread().getName().equals(FrameworkStartLevelImpl.THREAD_NAME))
{
synchronized (m_startLevelBundles)
{
if (!m_startLevelBundles.isEmpty())
{
// Only add the bundle to the start level bundles
// being process if it is not already there.
boolean found = false;
for (StartLevelTuple tuple : m_startLevelBundles)
{
if (tuple.m_bundle == bundle)
{
found = true;
}
}
if (!found)
{
...
m_startLevelBundles.add(new StartLevelTuple(bundle, bundleLevel));
}
return;
}
}
My solution is that :
1) in Felix class, adding a public method to observer whether m_startLevelBundles is empty or not until FelixStartLevel thread finished.
2) adding an api into StartLevel Service to make user or client see whether current bundle(tuple) is in m_startLevelBundles by 1)
In this way, once finding current bundle is in m_startLevelBundles, client will wait until FelixStartLevel thread finished and then execute start(int) method.
Do you agree with me?
Thanks
--Tang
> Bundle.start() returns without starting the bundle
> --------------------------------------------------
>
> Key: FELIX-3713
> URL: https://issues.apache.org/jira/browse/FELIX-3713
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.0.2
> Reporter: Sahoo
> Fix For: framework-4.2.0
>
>
> See email exchange between Sahoo & Richard that happened in dev alias on 16th Oct 2012 for issue details:
> > While investigating some issues in GlassFish, what we are seeing is that even if our code is calling bundle.start(START_TRANSIENT), the bundle is not getting started immediately, nor is the code blocking. It simply returns without Bundle's activator getting called and bundle.getState() == RESOLVED. We see this happening when there is a start level change in progress. We are currently using Felix 4.0.2. Looking at the code, I see this to be by design, but isn't it a non-compliant behavior? Should bundle.start() not wait until the bundle is started?
> The spec has always been a little lenient about how start levels are processed to give leeway to the frameworks. For us, we viewed this as somewhat of a race condition between threads starting bundles and the start level thread.
> However, in the transient case, I wouldn't expect it to remain in RESOLVED state. If its start level wasn't met, it should have thrown an exception. Yet there is a chance in the transient case that it could start asynchronously...not sure if this would really be problematic for you or not...
> But it shouldn't remain in the RESOLVED state. Looking at the code, I think there is a bug in this scenario where a transient bundle that is handled asynchronously will not actually end up getting started since the start level thread checks the persistent state of the bundle, which is not set for transient bundles.
> You could definitely open up a bug for this last issue...
> -> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3713) Bundle.start() returns without
starting the bundle
Posted by "TangYong (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510994#comment-13510994 ]
TangYong commented on FELIX-3713:
---------------------------------
Hi sahoo, richard,
About the issue happened on glassfish, according to richard's reply, while attempting to execute "bundle.start(Bundle.START_TRANSIENT)" and the bundle is used by FelixStartLevel thread, using the following method should resolve the issue,
1) before executing "bundle.start(Bundle.START_TRANSIENT), using StartLevel.getStartLevel() to seeing whether active start level value of the Framework is equal to the value of "glassfish.osgi.start.level.final".
2) if being equal, this means that basiclly Framework Acitve StartLevel has been adjusted, and m_startLevelBundles has removed the transient bundle, then, we start to execute "bundle.start(Bundle.START_TRANSIENT).
3) if not being equal, we do a loop until active start level value of the Framework is equal to the value of "glassfish.osgi.start.level.final", then, we start to execute "bundle.start(Bundle.START_TRANSIENT).
I will spend some time to validate the above.
Thanks
--Tang
> Bundle.start() returns without starting the bundle
> --------------------------------------------------
>
> Key: FELIX-3713
> URL: https://issues.apache.org/jira/browse/FELIX-3713
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.0.2
> Reporter: Sahoo
> Fix For: framework-4.2.0
>
>
> See email exchange between Sahoo & Richard that happened in dev alias on 16th Oct 2012 for issue details:
> > While investigating some issues in GlassFish, what we are seeing is that even if our code is calling bundle.start(START_TRANSIENT), the bundle is not getting started immediately, nor is the code blocking. It simply returns without Bundle's activator getting called and bundle.getState() == RESOLVED. We see this happening when there is a start level change in progress. We are currently using Felix 4.0.2. Looking at the code, I see this to be by design, but isn't it a non-compliant behavior? Should bundle.start() not wait until the bundle is started?
> The spec has always been a little lenient about how start levels are processed to give leeway to the frameworks. For us, we viewed this as somewhat of a race condition between threads starting bundles and the start level thread.
> However, in the transient case, I wouldn't expect it to remain in RESOLVED state. If its start level wasn't met, it should have thrown an exception. Yet there is a chance in the transient case that it could start asynchronously...not sure if this would really be problematic for you or not...
> But it shouldn't remain in the RESOLVED state. Looking at the code, I think there is a bug in this scenario where a transient bundle that is handled asynchronously will not actually end up getting started since the start level thread checks the persistent state of the bundle, which is not set for transient bundles.
> You could definitely open up a bug for this last issue...
> -> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3713) Bundle.start() returns without
starting the bundle
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496854#comment-13496854 ]
Richard S. Hall commented on FELIX-3713:
----------------------------------------
Yep, that's why we opened an issue on it. Thanks.
> Bundle.start() returns without starting the bundle
> --------------------------------------------------
>
> Key: FELIX-3713
> URL: https://issues.apache.org/jira/browse/FELIX-3713
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.0.2
> Reporter: Sahoo
> Fix For: framework-4.2.0
>
>
> See email exchange between Sahoo & Richard that happened in dev alias on 16th Oct 2012 for issue details:
> > While investigating some issues in GlassFish, what we are seeing is that even if our code is calling bundle.start(START_TRANSIENT), the bundle is not getting started immediately, nor is the code blocking. It simply returns without Bundle's activator getting called and bundle.getState() == RESOLVED. We see this happening when there is a start level change in progress. We are currently using Felix 4.0.2. Looking at the code, I see this to be by design, but isn't it a non-compliant behavior? Should bundle.start() not wait until the bundle is started?
> The spec has always been a little lenient about how start levels are processed to give leeway to the frameworks. For us, we viewed this as somewhat of a race condition between threads starting bundles and the start level thread.
> However, in the transient case, I wouldn't expect it to remain in RESOLVED state. If its start level wasn't met, it should have thrown an exception. Yet there is a chance in the transient case that it could start asynchronously...not sure if this would really be problematic for you or not...
> But it shouldn't remain in the RESOLVED state. Looking at the code, I think there is a bug in this scenario where a transient bundle that is handled asynchronously will not actually end up getting started since the start level thread checks the persistent state of the bundle, which is not set for transient bundles.
> You could definitely open up a bug for this last issue...
> -> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3713) Bundle.start() returns without
starting the bundle
Posted by "TangYong (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496808#comment-13496808 ]
TangYong commented on FELIX-3713:
---------------------------------
I think that the problem needs to be fixed in felix, I offer a real use case as following:
On glassfish starting, there is a Start Level thread to adjust Start Level, in the process of executing the Start Level thread, I have a bundle tracker to trace some bundle to start the bundle in order to finish something. I used bundle.start(Bundle.START_TRANSIENT) to start the bundle while tracing the bundle. However, the bundle's activator was not executed. If I used bundle.start() method to start the bundle while tracing the bundle, although the bundle's activator was executed, the bundle's ondemand starting(on some cases, the bundle maybe started by other handling logic) disappeared because bundle.start() method keeped bundle's state persisted.
So, I wish that felix team can fix it.
Thanks.
--Tang
> Bundle.start() returns without starting the bundle
> --------------------------------------------------
>
> Key: FELIX-3713
> URL: https://issues.apache.org/jira/browse/FELIX-3713
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.0.2
> Reporter: Sahoo
> Fix For: framework-4.2.0
>
>
> See email exchange between Sahoo & Richard that happened in dev alias on 16th Oct 2012 for issue details:
> > While investigating some issues in GlassFish, what we are seeing is that even if our code is calling bundle.start(START_TRANSIENT), the bundle is not getting started immediately, nor is the code blocking. It simply returns without Bundle's activator getting called and bundle.getState() == RESOLVED. We see this happening when there is a start level change in progress. We are currently using Felix 4.0.2. Looking at the code, I see this to be by design, but isn't it a non-compliant behavior? Should bundle.start() not wait until the bundle is started?
> The spec has always been a little lenient about how start levels are processed to give leeway to the frameworks. For us, we viewed this as somewhat of a race condition between threads starting bundles and the start level thread.
> However, in the transient case, I wouldn't expect it to remain in RESOLVED state. If its start level wasn't met, it should have thrown an exception. Yet there is a chance in the transient case that it could start asynchronously...not sure if this would really be problematic for you or not...
> But it shouldn't remain in the RESOLVED state. Looking at the code, I think there is a bug in this scenario where a transient bundle that is handled asynchronously will not actually end up getting started since the start level thread checks the persistent state of the bundle, which is not set for transient bundles.
> You could definitely open up a bug for this last issue...
> -> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3713) Bundle.start() returns without
starting the bundle
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-3713:
-----------------------------------
Fix Version/s: framework-4.2.0
> Bundle.start() returns without starting the bundle
> --------------------------------------------------
>
> Key: FELIX-3713
> URL: https://issues.apache.org/jira/browse/FELIX-3713
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.0.2
> Reporter: Sahoo
> Fix For: framework-4.2.0
>
>
> See email exchange between Sahoo & Richard that happened in dev alias on 16th Oct 2012 for issue details:
> > While investigating some issues in GlassFish, what we are seeing is that even if our code is calling bundle.start(START_TRANSIENT), the bundle is not getting started immediately, nor is the code blocking. It simply returns without Bundle's activator getting called and bundle.getState() == RESOLVED. We see this happening when there is a start level change in progress. We are currently using Felix 4.0.2. Looking at the code, I see this to be by design, but isn't it a non-compliant behavior? Should bundle.start() not wait until the bundle is started?
> The spec has always been a little lenient about how start levels are processed to give leeway to the frameworks. For us, we viewed this as somewhat of a race condition between threads starting bundles and the start level thread.
> However, in the transient case, I wouldn't expect it to remain in RESOLVED state. If its start level wasn't met, it should have thrown an exception. Yet there is a chance in the transient case that it could start asynchronously...not sure if this would really be problematic for you or not...
> But it shouldn't remain in the RESOLVED state. Looking at the code, I think there is a bug in this scenario where a transient bundle that is handled asynchronously will not actually end up getting started since the start level thread checks the persistent state of the bundle, which is not set for transient bundles.
> You could definitely open up a bug for this last issue...
> -> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3713) Bundle.start() returns without
starting the bundle
Posted by "TangYong (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510435#comment-13510435 ]
TangYong commented on FELIX-3713:
---------------------------------
>2) adding an api into StartLevel Service to make user or client see whether current bundle(tuple) is in m_startLevelBundles by 1)
I know that adding api for StartLevel will change OSGi Core Specification, maybe you do not agree with me, however, from a user's perspective, this should be a good way to resolve such a problem, after all, in current OSGi Core Specification, when appearing such a scene, there is not a clear description.
> Bundle.start() returns without starting the bundle
> --------------------------------------------------
>
> Key: FELIX-3713
> URL: https://issues.apache.org/jira/browse/FELIX-3713
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.0.2
> Reporter: Sahoo
> Fix For: framework-4.2.0
>
>
> See email exchange between Sahoo & Richard that happened in dev alias on 16th Oct 2012 for issue details:
> > While investigating some issues in GlassFish, what we are seeing is that even if our code is calling bundle.start(START_TRANSIENT), the bundle is not getting started immediately, nor is the code blocking. It simply returns without Bundle's activator getting called and bundle.getState() == RESOLVED. We see this happening when there is a start level change in progress. We are currently using Felix 4.0.2. Looking at the code, I see this to be by design, but isn't it a non-compliant behavior? Should bundle.start() not wait until the bundle is started?
> The spec has always been a little lenient about how start levels are processed to give leeway to the frameworks. For us, we viewed this as somewhat of a race condition between threads starting bundles and the start level thread.
> However, in the transient case, I wouldn't expect it to remain in RESOLVED state. If its start level wasn't met, it should have thrown an exception. Yet there is a chance in the transient case that it could start asynchronously...not sure if this would really be problematic for you or not...
> But it shouldn't remain in the RESOLVED state. Looking at the code, I think there is a bug in this scenario where a transient bundle that is handled asynchronously will not actually end up getting started since the start level thread checks the persistent state of the bundle, which is not set for transient bundles.
> You could definitely open up a bug for this last issue...
> -> richard
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira