Andrey Chernyshev wrote:
On 8/22/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I've applied the thread manager patch (with some minor tweaks by hand...)
All builds fine, and passes the smoke tests and the new [cool] C-based
unit tests.
However, when I run tomcat 5.5.17, I have a problem - after the server
comes up, it throws an exception and then spins hard.
Which platform/configuration you are running it? To be honest, I never
run tomcat with DRLVM so I don' t know what the issue could be.
I'm trying to reproduce what you described, but so far the tomcat
seems to start successfully for me at least with win/debug:
C:\temp\apache-tomcat-5.5.17\bin>c:\workspace\trunk-vm\drlvm\build\win_ia32_msvc
_debug\deploy\jre\bin\java
-Djava.util.logging.manager=org.apache.juli.ClassLoa
derLogManager
-Djava.util.logging.config.file="C:\temp\apache-tomcat-5.5.17\conf
\logging.properties"
-Djava.endorsed.dirs="C:\temp\apache-tomcat-5.5.17\common
\endorsed" -classpath "C:\temp\apache-tomcat-5.5.17\bin\bootstrap.jar"
-Dcatalin
a.base="C:\temp\apache-tomcat-5.5.17"
-Dcatalina.home="C:\temp\apache-tomcat-5.5
.17" -Djava.io.tmpdir="C:\temp\apache-tomcat-5.5.17\temp"
org.apache.catalina.st
artup.Bootstrap start
...
<snip>
...
Aug 22, 2006 10:14:46 PM INFO
org.apache.catalina.startup.Catalina.start: Server
startup in 8653 ms
I even can see a web page at localhost:8080...
I've just got the fresh classlib and drlvm.
Could it be that we resolved the conflicts differently?
I don't think so :) I'm on Ubuntu 6. And "I don't think so" because I
can get the problem to happen on other builds as well, but it just takes
longer.
For example, using head, it took 1 hour and 11 minutes for the problem
to occur. It was just sitting there, waiting.
But it's the same problem - a socket exception in luni's
OSNetworkSystem.acceptStreamStockeImpl()
I'll test on snapshot for last week.
I've done a sanity check with last weeks published snapshot, and SVN
head w/o the threadmanager patch (to test if it's the classlib) and both
work fine.
I'd like to get TM in so that VM patches can be based against that, but
I'm a little loathe to commit what appears to be broken code.
So what to do?
If we believe that we can get this fixed quickly against SVN, I'm happy
to check in and let people work on it directly - I think that would be
the nicest way to continue moving all work against the Harmony SVN...
If I find what the problem is, I think I could suggest the updated
patch or a follow-up patch that can be applied prior to the
integration/commit.
Still, may be it won't be a bad idea to integrate this code now
because next time the conflicts could be harder to resolve - it really
touches a lot.
May be creating a separate branch could help for now?
If this is something that always has been there, and the TM patch just
makes it happen faster, we might as well commit the TM patch and solve
it head on...
geir
Thanks,
Andrey.
Andrey, et al - do you think this is minor?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
