Re: [equinox-dev] equinox bundle akin to felix fileinstall

2012-10-31 Thread Raymond Auge
Sadly, this is an ongoing issue with fileinstall even in the latest release
(3.2.6).

It seems that fileinstall thread is interrupted while waiting for the
refresh to complete.


On Mon, Jun 18, 2012 at 8:38 AM, Thomas Watson tjwat...@us.ibm.com wrote:

 I think part of the problem is that file install is not waiting for the
 refresh operation to complete before attempting to start all the bundles.
  See https://issues.apache.org/jira/browse/FELIX-3414

 What I think ends up happening is that file install calls start on the
 bundles it has just installed after it has called an async refresh packages
 operation.  This grabs a state change lock for the bundle.  Now this lock
 prevents the refresh packages background thread to obtain the state change
 lock for the bundle that is being activated.  You may want to give the
 latest file install code a try to see if it fixes your issue.

 Tom



 [image: Inactive hide details for hbdrawn ---06/15/2012 07:13:53 PM---I
 think the operation of refreshing for uninstalledBundles and]hbdrawn
 ---06/15/2012 07:13:53 PM---I think the operation of refreshing for
 uninstalledBundles and updatedBundles is required, but not for
 installBundles。And ma



From:


 hbdrawn hbdr...@vip.qq.com

To:


 Equinox development mailing list equinox-dev@eclipse.org,

Date:


 06/15/2012 07:13 PM

Subject:


 [equinox-dev] 回复: 回复: equinox bundle akin to felix fileinstall
 --



 I think the  operation of refreshing for uninstalledBundles and
 updatedBundles is required, but not for installBundles。And maybe there are
 some faults just like what Raymond said.
 --
 学会滑翔,宁静致远||梦依旧



 -- 原始邮件 --
 *发件人:* Raymond Augeraymond.a...@liferay.com;
 *发送时间:* 2012年6月16日(星期六) 凌晨5:49
 *收件人:* Equinox development mailing listequinox-dev@eclipse.org;
 *主题:* Re: [equinox-dev]回复: equinox bundle akin to felix fileinstall

 On Fri, Jun 15, 2012 at 10:23 AM, hbdrawn 
 *hbdr...@vip.qq.com*hbdr...@vip.qq.com
 wrote:

i encoutered  the same problem before.After checked out the code,i
found the *spilth* code in the line of 502(maybe the original code had
been modified  somewhere,so the line is not correct maybe,but the code
below is right,please check it) in the DirectoryWatcher.java( function
process):

toRefresh.addAll( uninstalledBundles );
toRefresh.addAll(updatedBundles);
//toRefresh.addAll( installedBundles );


 This actually does seem to be the issue. Again I'm not sure who is at
 fault because internally equinox is performing a refresh on bundles using a
 separate thread which would clearly seem to violate the code in
 AbstractBundle.beginStateChange which will quite clearly throw an error it
 a separate thread has the bundle in a dirty state.

 Perhaps there is no need for felix file install to actually force a
 package refresh? Wouldn't that be automatically done by the framework
 itself on an install/update/deletion?

 Perhaps it's because it's trying to perform the process as a batch?

 Here is the exact code in question:

 // Handle deleted artifacts
 // We do the operations in the following order:
 // uninstall, update, install, refresh  start.
 Collection uninstalledBundles = uninstall(deleted);
 Collection updatedBundles = update(modified);
 Collection installedBundles = install(created);

 Set toRefresh = new HashSet();
 toRefresh.addAll( uninstalledBundles );
 toRefresh.addAll(updatedBundles);
 toRefresh.addAll( installedBundles );
 findBundlesWithFragmentsToRefresh( toRefresh );
 findBundlesWithOptionalPackagesToRefresh( toRefresh );
 if (toRefresh.size()  0)
 {
 // Refresh if any bundle got uninstalled or updated.
 *refresh((Bundle[]) toRefresh.toArray(new
 Bundle[toRefresh.size()]));*
 }

 The error results from the second last line above, but if we comment the
 line as bdrawn mentions above, then it eliminates the error, but does it
 leave the system in a state it shouldn't be in?

 -- *
 *
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile 
 http://twitter.com/#!/rotty3000 |
 Senior Software Architect | *Liferay, Inc.* http://www.liferay.com/ 
 https://twitter.com/#!/liferay

 ---

 8-9 October 2012 |* Liferay **North America Symposium* | *
 liferay.com/northamerica2012* http://www.liferay.com/northamerica2012

 16-17 October 2012 |* Liferay **Europe Symposium* | *
 liferay.com/europe2012* http://www.liferay.com/europe2012

 24-25 October 2012 |* Liferay **Spain Symposium* | 
 *liferay.com/spain2012*http://www.liferay.com/spain2012

 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev


 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman

Re: [equinox-dev] equinox bundle akin to felix fileinstall

2012-06-15 Thread Thomas Watson

The closest thing is the dropins support in p2, but that is not a good
comparison since felix fileinstall is a small single bundle.  p2 dropins
support is just a part of the whole p2 engine and requires a fair bit of
the p2 engine to function.

I would be curious to know what exceptions you are seeing with
felix.fileinstall.  Perhaps it indicates an equinox framework bug we should
fix.  Please open a bug against Equinox-Framework if you think it could
be.  I would like to make sure the felix.fileinstall works on Equinox.

Tom




   
  From:   Raymond Auge raymond.a...@liferay.com  
   
  To: Equinox development mailing list equinox-dev@eclipse.org,
   
  Date:   06/15/2012 08:32 AM  
   
  Subject:[equinox-dev] equinox bundle akin to felix fileinstall   
   





Is there such a project?

I'm having issues with felix.fileinstall on equinox (exceptions on change
state) and wondering if I can save myself the trouble if there is a more
native implementation similar to it.

Thx
--
Raymond Augé  | Senior Software Architect | Liferay, Inc.


---


8-9 October 2012 | Liferay North America Symposium |
liferay.com/northamerica2012


16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012


24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





inline: graycol.gifinline: ecblank.gif___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Re: [equinox-dev] equinox bundle akin to felix fileinstall

2012-06-15 Thread Raymond Auge
On Fri, Jun 15, 2012 at 9:36 AM, Thomas Watson tjwat...@us.ibm.com wrote:

 The closest thing is the dropins support in p2, but that is not a good
 comparison since felix fileinstall is a small single bundle.  p2 dropins
 support is just a part of the whole p2 engine and requires a fair bit of
 the p2 engine to function.


Yeah, that's too heavy for my needs.


 I would be curious to know what exceptions you are seeing with
 felix.fileinstall.  Perhaps it indicates an equinox framework bug we should
 fix.  Please open a bug against Equinox-Framework if you think it could
 be.  I would like to make sure the felix.fileinstall works on Equinox.

This the thing. I'm not even sure it's a bug, or simply something in my env
that is causing it.

Here is the logged exception:

org.osgi.framework.BundleException: State change in progress for bundle
file:/home/rotty/apache-tomcat-7.0.23-trunk/repositories/osgi/data/framework/lib/web-extender-spi.jar
by thread
fileinstall-/home/rotty/apache-tomcat-7.0.23-trunk/repositories/osgi/data/framework/lib.
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:330)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
at java.lang.Thread.run(Thread.java:679)
Caused by:
org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
... 6 more

It seems that the package resolver thread is reacting to the new bundle
while the fileinstall thread is still deploying it. I'm not sure who's at
fault; fileinstall or equinox (of something else).

-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
http://twitter.com/#!/rotty3000 | Senior Software Architect | *Liferay,
Inc.* http://www.liferay.com  https://twitter.com/#!/liferay

---

8-9 October 2012 |* Liferay **North America Symposium* |
liferay.com/northamerica2012 http://www.liferay.com/northamerica2012

16-17 October 2012 |* Liferay **Europe Symposium* |
liferay.com/europe2012http://www.liferay.com/europe2012

24-25 October 2012 |* Liferay **Spain Symposium* |
liferay.com/spain2012http://www.liferay.com/spain2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Re: [equinox-dev] equinox bundle akin to felix fileinstall

2012-06-15 Thread Neil Bartlett
I think it's more likely that FileInstall is seeing the file and trying to
install it while the external process (whatever that might be) is still
writing it to the disk. Short of hooking into the OS filesystem events
(which would require platform-specific native code), any Fileinstall-like
bundle will have the same problem.

To alleviate this problem, FileInstall has a configurable timer, i.e. it
will only look at the file if it stops changing for a period of time. Maybe
you just need to increase the length of that timer. Unfortunately I don't
recall exactly how to do that.

Regards
Neil

On Fri, Jun 15, 2012 at 2:43 PM, Raymond Auge raymond.a...@liferay.comwrote:

 On Fri, Jun 15, 2012 at 9:36 AM, Thomas Watson tjwat...@us.ibm.comwrote:

  The closest thing is the dropins support in p2, but that is not a good
 comparison since felix fileinstall is a small single bundle.  p2 dropins
 support is just a part of the whole p2 engine and requires a fair bit of
 the p2 engine to function.


 Yeah, that's too heavy for my needs.


 I would be curious to know what exceptions you are seeing with
 felix.fileinstall.  Perhaps it indicates an equinox framework bug we should
 fix.  Please open a bug against Equinox-Framework if you think it could
 be.  I would like to make sure the felix.fileinstall works on Equinox.

 This the thing. I'm not even sure it's a bug, or simply something in my
 env that is causing it.

 Here is the logged exception:

 org.osgi.framework.BundleException: State change in progress for bundle
 file:/home/rotty/apache-tomcat-7.0.23-trunk/repositories/osgi/data/framework/lib/web-extender-spi.jar
 by thread
 fileinstall-/home/rotty/apache-tomcat-7.0.23-trunk/repositories/osgi/data/framework/lib.
  at
 org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
  at
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:330)
 at
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
  at
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
  at
 org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
 at java.lang.Thread.run(Thread.java:679)
 Caused by:
 org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
 ... 6 more

 It seems that the package resolver thread is reacting to the new bundle
 while the fileinstall thread is still deploying it. I'm not sure who's at
 fault; fileinstall or equinox (of something else).

 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 http://twitter.com/#%21/rotty3000 | Senior Software Architect | *Liferay,
 Inc.* http://www.liferay.com  https://twitter.com/#%21/liferay

 ---

 8-9 October 2012 |* Liferay **North America Symposium* |
 liferay.com/northamerica2012 http://www.liferay.com/northamerica2012

 16-17 October 2012 |* Liferay **Europe Symposium* | 
 liferay.com/europe2012http://www.liferay.com/europe2012

 24-25 October 2012 |* Liferay **Spain Symposium* | 
 liferay.com/spain2012http://www.liferay.com/spain2012



 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


[equinox-dev] ?????? ?????? equinox bundle akin to felix fileinstall

2012-06-15 Thread hbdrawn
I think the  operation of refreshing for uninstalledBundles and updatedBundles 
is required, but not for installBundles??And maybe there are some faults just 
like what Raymond said.--
??||??


 




--  --
??: Raymond Augeraymond.a...@liferay.com;
: 2012??6??16??(??) 5:49
??: Equinox development mailing listequinox-dev@eclipse.org; 

: Re: [equinox-dev]?? equinox bundle akin to felix fileinstall



On Fri, Jun 15, 2012 at 10:23 AM, hbdrawn hbdr...@vip.qq.com wrote:
 i encoutered  the same problem before.After checked out the code,i found the 
spilth   code in the line of 502(maybe the original code had been modified  
somewhere,so the line is not correct maybe,but the code below is right,please 
check it) in the DirectoryWatcher.java( function process):
 
 toRefresh.addAll( uninstalledBundles );
toRefresh.addAll(updatedBundles);
//toRefresh.addAll( installedBundles );


This actually does seem to be the issue. Again I'm not sure who is at fault 
because internally equinox is performing a refresh on bundles using a separate 
thread which would clearly seem to violate the code in 
AbstractBundle.beginStateChange which will quite clearly throw an error it a 
separate thread has the bundle in a dirty state.
 

Perhaps there is no need for felix file install to actually force a package 
refresh? Wouldn't that be automatically done by the framework itself on an 
install/update/deletion? 


 Perhaps it's because it's trying to perform the process as a batch?


Here is the exact code in question:


// Handle deleted artifacts
 // We do the operations in the following order:
// uninstall, update, install, refresh  start.
 Collection uninstalledBundles = uninstall(deleted);
Collection updatedBundles = update(modified);
 Collection installedBundles = install(created);

Set toRefresh = new HashSet();
 toRefresh.addAll( uninstalledBundles );
toRefresh.addAll(updatedBundles);
toRefresh.addAll( installedBundles );
 findBundlesWithFragmentsToRefresh( toRefresh );
findBundlesWithOptionalPackagesToRefresh( toRefresh );
 if (toRefresh.size()  0)
{
// Refresh if any bundle got uninstalled or updated.
 refresh((Bundle[]) toRefresh.toArray(new 
Bundle[toRefresh.size()]));
}



 The error results from the second last line above, but if we comment the line 
as bdrawn mentions above, then it eliminates the error, but does it leave the 
system in a state it shouldn't be in?
 


-- 
Raymond Aug??  | Senior Software Architect | Liferay, Inc.  
---

8-9 October 2012 | Liferay North America Symposium | 
liferay.com/northamerica2012
 
16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012
 
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev