Rajini Sivaram wrote:
On 3/17/08, Simon Nash <[EMAIL PROTECTED]> wrote:
Rajini Sivaram wrote:
Simon,
Sorry about that. I hadn't done a clean build, so I didn't notice that
binding-feed-atom didn't exist anymore.
I did an svn up to pick up the latest itest/osgi-tuscany changes and
I got further this time. The modules all built but I got test failures.
Here's the stack trace from the tests. Sorry that it is long but there
seem be multiple failures of different severity. Any ideas?
Simon,
I haven't seen the exception you are seeing (the first one in your log). Is
it possible that you may be running out of disk space? I just realized that
Felix caches bundles, and hence requires quite a lot of disk space to run
Tuscany. So the total disk space required to build and run osgi-tuscany is
close to 180M - it is at this point that I should take back the request to
add osgi-tuscany to the build.
This 180M figure for peak disk space consumption is consistent with what
I am seeing. The time taken for the tests that I am able to run is
slightly more than the total time taken by the current full Tuscany build
(22 mins for osgi-tuscany vs 20 mins for the rest of the build,
using a fast machine, so the total build time would approximately
double from ~20 mins to ~40 mins if this were included). Doubling the
build time is the biggest problem for me, as this would have a very
large impact on my productivity. The 180MB space overhead is less of
a showstopper but would be inconvenient.
However I have still not got the tests to run to completion, so it's
possible that the final figures for space and time could be different
for an osgi-tuscany build that runs successfully to completion.
Am I right in assuming that you are using the Sun JDK? Jurgen had also run
into the OutOfMemory problem with perm gen space (the error right at the end
of your log), which I haven't run into with the IBM JDK. It almost looks
like Sun's JDK doesn't manage to garbage collect fully after an OSGi run
(maybe classes are not GC'ed even after the classloader is unreachable, I am
not sure). I have modified the test pom to fork a new VM for each test to
avoid that error. That does slow down the tests, but at least they will run
(hopefully).
Yes I am running on the Sun JDK. With the "fork" change, I get much
further, though I still don't get a clean build. I monitored disk
space usage throughout the test run and I am not running out of space.
Here is a summary of the errors I am seeing now. I have opened TUSCANY-2097
to track this and I have posted my full build log there.
1. revision.location error creating archive. This seems to show up on
every test, and it does not seem to cause a hard failure in the test.
java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-
test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th
e file specified)
ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja
va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te
st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the
file specified))
2. InvocationTargetException in CalculatorRMIReferencetestCase.
java.lang.reflect.InvocationTargetException
.....
Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex
ception is:
java.net.BindException: Address already in use: JVM_Bind
3. Various errors in testOSGiTuscany_BindingWS
-> ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi
ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test
\bundle5
java.util.zip.ZipException: The system cannot find the file specified
org.osgi.framework.BundleException: Could not create bundle object.
.....
Caused by: java.util.zip.ZipException: The system cannot find the file specified
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
