You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/08/22 18:11:48 UTC
[drlvm] problem when TM patch applied
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.
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...
Andrey, et al - do you think this is minor?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Yes, I'm suspicious too :)
But I'm also redoing all my work, to be sure that what I am calling the
'head + TM patch' is clean. There's a chance that building w/
federation reverted (in the SVN sense) some files.
I'll report back in a few
geir
Gregory Shimansky wrote:
> On Wednesday 23 August 2006 02:35 Rana Dasgupta wrote:
>> On 8/22/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>>> it also exhibited the same problem on Ubuntu 5 running in Parallels on a
>>>> mac.
>>>>
>>>> the tgz can be found here :
>>> http://people.apache.org/~geirm/incubator-harmony-jre-r433739-linux-x86-3
>>> 2-snapshot
>>>
>>>> .tar.gz
>>>>
>>>> if someone wants to try it on some other linux...
>> It may not be the same problem as the 1 hour 11 minute problem with last
>> week's distribution, even if the exception is the same. (I saw bugs in the
>> Tomcat database related to accept timeouts leading to similar
>> exceptions over time) . I can try to start up and keep it running on W2003.
>>
>> If this is not Ubuntu specific and it is so immediate, we probabay should
>> not commit till we know what's going on.
>
> According to Geir the snapshot from last week lasted just one minute more :)
>
> It exception is the same, time is the same, then what is the difference?
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by Jean-frederic Clere <jf...@gmail.com>.
Geir Magnusson Jr. wrote:
> Jean-frederic Clere wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> Rana Dasgupta wrote:
>>>
>>>> On 8/22/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>
>>>>>
>>>>> >According to Geir the snapshot from last week lasted just one
>>>>> minute more
>>>>> :)
>>>>>
>>>>> >It exception is the same, time is the same, then what is the
>>>>> difference?
>>>>
>>>>
>>>>
>>>>
>>>> I most likely misread. I thought that Geir was saying that with the
>>>> TM patch
>>>> the exception is raised instantly and repeats. Without the TM
>>>> patch, it
>>>> happens after an hour both with last week's snapshot and with the
>>>> current
>>>> SVN head.
>>>
>>>
>>>
>>> So I've retried with a clean build, and then the new 1.2M patch from
>>> Salikh (that impressively does apply cleanly) and both result in the
>>> same - the failure I reported w/o 10 seconds of start up with tomcat.
>>>
>>> I think the thing to do here is :
>>>
>>> 1) really hope that someone can reproduce it tonight
>>
>>
>> With head without the patch I have (TC goes on working after):
>
>
> [SNIP]
>
>> Aug 23, 2006 8:37:42 AM INFO
>> org.apache.catalina.startup.Catalina.start: Server startup in 6611 ms
>> Aug 23, 2006 8:40:15 AM WARNING
>> org.apache.jk.common.ChannelSocket.acceptConnections: Exception
>> executing accept
>> Throwable occurred: java.net.SocketException: Interrupted system call
>> at
>> org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocketImpl(OSNetworkSystem.java)
>
>
>
> [SNIP]
>
> Odd. What platform/OS?
RHEL4 on i686.
Cheers
Jean-Frederic
> Foro you, it happened in 2.5 min or so, not the hour it took me.
> (Boy, this would have saved me time yesterday....)
>
>
>> I have not tried with the patch.
>>
>> The weird thing is that I would also expect it on the ajp13 socket
>> but I don't get it.
>>
>
> Thanks for doing this...
>
> geir
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Jean-frederic Clere wrote:
> Geir Magnusson Jr. wrote:
>
>> Rana Dasgupta wrote:
>>
>>> On 8/22/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>>
>>>>
>>>> >According to Geir the snapshot from last week lasted just one
>>>> minute more
>>>> :)
>>>>
>>>> >It exception is the same, time is the same, then what is the
>>>> difference?
>>>
>>>
>>>
>>> I most likely misread. I thought that Geir was saying that with the
>>> TM patch
>>> the exception is raised instantly and repeats. Without the TM patch, it
>>> happens after an hour both with last week's snapshot and with the
>>> current
>>> SVN head.
>>
>>
>> So I've retried with a clean build, and then the new 1.2M patch from
>> Salikh (that impressively does apply cleanly) and both result in the
>> same - the failure I reported w/o 10 seconds of start up with tomcat.
>>
>> I think the thing to do here is :
>>
>> 1) really hope that someone can reproduce it tonight
>
> With head without the patch I have (TC goes on working after):
[SNIP]
> Aug 23, 2006 8:37:42 AM INFO org.apache.catalina.startup.Catalina.start:
> Server startup in 6611 ms
> Aug 23, 2006 8:40:15 AM WARNING
> org.apache.jk.common.ChannelSocket.acceptConnections: Exception
> executing accept
> Throwable occurred: java.net.SocketException: Interrupted system call
> at
> org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocketImpl(OSNetworkSystem.java)
[SNIP]
Odd. What platform/OS? Foro you, it happened in 2.5 min or so, not the
hour it took me. (Boy, this would have saved me time yesterday....)
> I have not tried with the patch.
>
> The weird thing is that I would also expect it on the ajp13 socket but I
> don't get it.
>
Thanks for doing this...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by Jean-frederic Clere <jf...@gmail.com>.
Geir Magnusson Jr. wrote:
> Rana Dasgupta wrote:
>
>> On 8/22/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>>>
>>> >According to Geir the snapshot from last week lasted just one
>>> minute more
>>> :)
>>>
>>> >It exception is the same, time is the same, then what is the
>>> difference?
>>
>>
>>
>> I most likely misread. I thought that Geir was saying that with the
>> TM patch
>> the exception is raised instantly and repeats. Without the TM patch, it
>> happens after an hour both with last week's snapshot and with the
>> current
>> SVN head.
>
>
> So I've retried with a clean build, and then the new 1.2M patch from
> Salikh (that impressively does apply cleanly) and both result in the
> same - the failure I reported w/o 10 seconds of start up with tomcat.
>
> I think the thing to do here is :
>
> 1) really hope that someone can reproduce it tonight
With head without the patch I have (TC goes on working after):
+++
Aug 23, 2006 8:37:41 AM INFO
org.apache.coyote.http11.Http11BaseProtocol.start: Starting Coyote
HTTP/1.1 on http-8080
Aug 23, 2006 8:37:41 AM INFO org.apache.jk.common.ChannelSocket.init:
JK: ajp13 listening on /0.0.0.0:8009
Aug 23, 2006 8:37:41 AM INFO org.apache.jk.server.JkMain.start: Jk
running ID=0 time=1/105 config=null
Aug 23, 2006 8:37:42 AM INFO
org.apache.catalina.storeconfig.StoreLoader.load: Find registry
server-registry.xml at classpath resource
Aug 23, 2006 8:37:42 AM INFO org.apache.catalina.startup.Catalina.start:
Server startup in 6611 ms
Aug 23, 2006 8:40:15 AM WARNING
org.apache.jk.common.ChannelSocket.acceptConnections: Exception
executing accept
Throwable occurred: java.net.SocketException: Interrupted system call
at
org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocketImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocket(OSNetworkSystem.java:220)
at
org.apache.harmony.luni.net.PlainSocketImpl.accept(PlainSocketImpl.java:101)
at java.net.ServerSocket.implAccept(ServerSocket.java:252)
at java.net.ServerSocket.accept(ServerSocket.java:140)
...
Aug 23, 2006 8:40:15 AM SEVERE
org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket: Endpoint
ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8080] ignored
exception: java.net.SocketException: Interrupted system call
...
+++
I have not tried with the patch.
The weird thing is that I would also expect it on the ajp13 socket but I
don't get it.
Cheers
Jean-Frederic
>
> 2) check the pile in tomorrow and force us to fix it ASAP
>
> geir
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Artem Aliev wrote:
>
> Following patch to hysock.c fixes the problem in hysock.
> Probably classlib experts could provide better way to fix this problem.
>
> --
> Artem Aliev, Intel Middleware Products Division
>
> --- modules/luni/src/main/native/port/linux/hysock.c
> +++ modules/luni/src/main/native/port/linux/hysock.c
> @@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
> I_32 rc = 0;
> I_32 result = 0;
>
> - result =
> + do
> + {
> + result =
> select (nfds, readfds == NULL ? NULL : &readfds->handle,
> writefds == NULL ? NULL : &writefds->handle,
> exceptfds == NULL ? NULL : &exceptfds->handle,
> timeout == NULL ? NULL : &timeout->time);
> + }
> + while (result == -1 && errno == EINTR);
> +
> if (result == -1)
> {
> rc = errno;
>
So, here's what bothers me - while it does fix the problem, it's fairly
course-grained. Why are we so sure we want to restart the select on any
interruption?
Could we simply :
1) ask the TM what signal it's using (because we might offer the option
to change this via command line like RI)
2) on a per-thread basis, mask out that signal (and any other we know
about) that we're using internally using pthread_sigmask ?
I don't remember my pthreads well enough. Sad.
One immediate downside is that we're still susceptible to signals user
JNI code is using, but that may be the expected state of things.
If anyone knows, I'm interested.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Geir Magnusson Jr. wrote:
> Artem Aliev wrote:
>> Gier,
>>
>> The DRLVM uses SIGUSR2 in thread suspend algorithm.
>> hysock_select() returns EINTR error when the signal appears, and
>> Socket.accept() throws exception.
>>
>> The New ThreadManager use thread_suspend() more extensively ( in lock
>> reservation algorithm). So the problem appears more frequently.
>
> Excellent - I knew there had to be an explanation as to why the same
> symptom appears so much faster...
>
>>
>> Following patch to hysock.c fixes the problem in hysock.
>> Probably classlib experts could provide better way to fix this problem.
>>
>
> This seems wrong - that we're going to make it everyone else's problem
> because we're using SIGUSR2. Is there a way to setup a handler such
> that select() (and other things scattered about, including user native
> code) don't have to worry about this?
Well, a quick read of Stevens says "apparently not" :) It's been about
8 years since I did this kind of thing in anger.
I suspect Dalibor has a suggestion here because of Kaffe :)
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 8/23/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> Artem Aliev wrote:
>> > Gier,
>> >
>> > The DRLVM uses SIGUSR2 in thread suspend algorithm.
>> > hysock_select() returns EINTR error when the signal appears, and
>> > Socket.accept() throws exception.
>> >
>> > The New ThreadManager use thread_suspend() more extensively ( in lock
>> > reservation algorithm). So the problem appears more frequently.
>>
>> Excellent - I knew there had to be an explanation as to why the same
>> symptom appears so much faster...
>>
>> >
>> > Following patch to hysock.c fixes the problem in hysock.
>> > Probably classlib experts could provide better way to fix this problem.
>> >
>>
>> This seems wrong - that we're going to make it everyone else's problem
>
> The other way we can look at this as if the DRLVM was an arbitrary
> user application code which is utilizing SIGUSR2 for some reason.
> In this case the hysock implementation appears to be not immune to
> such user code.
>
True - I wasn't meaning to imply that DRLVM was the problem, I was just
thinking in the larger sense (what about user code via JNI?). Sorry.
>
>> because we're using SIGUSR2. Is there a way to setup a handler such
>> that select() (and other things scattered about, including user native
>> code) don't have to worry about this?
>
> I think that DRLVM correctly installs the SIGUSR2 handler with the
> SA_RESTART flag which means that the interrupted function should be
> restarted.
> It looks like the actual problem here is that the select()
> implementation on Linux is not restartable (POSIX says this is up to
> specific select() implementation whether to restart or not).
Yes - Stevens talked about this exact issue, and you shouldn't depend on
things like select() being restarted if you are writing portable code.
I assume that people still use Stevens as a source for this stuff? Or
is there something newer? (I need something in electronic form, as I'd
have to buy a second airplane ticket just to have some place to put the
Stevens book...)
> This can be workarounded in the hysock.c in a way that Artem suggested.
>
> Note that the reference VM is also using SIGUSR2 for it's internal
> purposes in the default configuration (see
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html), so
> the DRLVM doesn't imply any additional restrictions on the user's code
> from this point of view.
Perfect. I just didn't know, and this answers the question.
> We may need, however, to add a command line option proposing usage of
> the alternative signals similar to what RI does.
>
> Anyways, it might be good if we can make the hysock implementation
> more robust wrt signals.
I agree 100%. I'll check in the code, and then work on the hysock issue...
thx
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by Andrey Chernyshev <a....@gmail.com>.
On 8/23/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Artem Aliev wrote:
> > Gier,
> >
> > The DRLVM uses SIGUSR2 in thread suspend algorithm.
> > hysock_select() returns EINTR error when the signal appears, and
> > Socket.accept() throws exception.
> >
> > The New ThreadManager use thread_suspend() more extensively ( in lock
> > reservation algorithm). So the problem appears more frequently.
>
> Excellent - I knew there had to be an explanation as to why the same
> symptom appears so much faster...
>
> >
> > Following patch to hysock.c fixes the problem in hysock.
> > Probably classlib experts could provide better way to fix this problem.
> >
>
> This seems wrong - that we're going to make it everyone else's problem
The other way we can look at this as if the DRLVM was an arbitrary
user application code which is utilizing SIGUSR2 for some reason.
In this case the hysock implementation appears to be not immune to
such user code.
> because we're using SIGUSR2. Is there a way to setup a handler such
> that select() (and other things scattered about, including user native
> code) don't have to worry about this?
I think that DRLVM correctly installs the SIGUSR2 handler with the
SA_RESTART flag which means that the interrupted function should be
restarted.
It looks like the actual problem here is that the select()
implementation on Linux is not restartable (POSIX says this is up to
specific select() implementation whether to restart or not).
This can be workarounded in the hysock.c in a way that Artem suggested.
Note that the reference VM is also using SIGUSR2 for it's internal
purposes in the default configuration (see
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html), so
the DRLVM doesn't imply any additional restrictions on the user's code
from this point of view.
We may need, however, to add a command line option proposing usage of
the alternative signals similar to what RI does.
Anyways, it might be good if we can make the hysock implementation
more robust wrt signals.
Thanks,
Andrey.
>
> Thanks for nailing this so quickly.
>
> geir
>
> > --
> > Artem Aliev, Intel Middleware Products Division
> >
> > --- modules/luni/src/main/native/port/linux/hysock.c
> > +++ modules/luni/src/main/native/port/linux/hysock.c
> > @@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
> > I_32 rc = 0;
> > I_32 result = 0;
> >
> > - result =
> > + do
> > + {
> > + result =
> > select (nfds, readfds == NULL ? NULL : &readfds->handle,
> > writefds == NULL ? NULL : &writefds->handle,
> > exceptfds == NULL ? NULL : &exceptfds->handle,
> > timeout == NULL ? NULL : &timeout->time);
> > + }
> > + while (result == -1 && errno == EINTR);
> > +
> > if (result == -1)
> > {
> > rc = errno;
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Artem Aliev wrote:
> Gier,
>
> The DRLVM uses SIGUSR2 in thread suspend algorithm.
> hysock_select() returns EINTR error when the signal appears, and
> Socket.accept() throws exception.
>
> The New ThreadManager use thread_suspend() more extensively ( in lock
> reservation algorithm). So the problem appears more frequently.
Excellent - I knew there had to be an explanation as to why the same
symptom appears so much faster...
>
> Following patch to hysock.c fixes the problem in hysock.
> Probably classlib experts could provide better way to fix this problem.
>
This seems wrong - that we're going to make it everyone else's problem
because we're using SIGUSR2. Is there a way to setup a handler such
that select() (and other things scattered about, including user native
code) don't have to worry about this?
Thanks for nailing this so quickly.
geir
> --
> Artem Aliev, Intel Middleware Products Division
>
> --- modules/luni/src/main/native/port/linux/hysock.c
> +++ modules/luni/src/main/native/port/linux/hysock.c
> @@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
> I_32 rc = 0;
> I_32 result = 0;
>
> - result =
> + do
> + {
> + result =
> select (nfds, readfds == NULL ? NULL : &readfds->handle,
> writefds == NULL ? NULL : &writefds->handle,
> exceptfds == NULL ? NULL : &exceptfds->handle,
> timeout == NULL ? NULL : &timeout->time);
> + }
> + while (result == -1 && errno == EINTR);
> +
> if (result == -1)
> {
> rc = errno;
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by Artem Aliev <ar...@gmail.com>.
Gier,
The DRLVM uses SIGUSR2 in thread suspend algorithm.
hysock_select() returns EINTR error when the signal appears, and
Socket.accept() throws exception.
The New ThreadManager use thread_suspend() more extensively ( in lock
reservation algorithm). So the problem appears more frequently.
Following patch to hysock.c fixes the problem in hysock.
Probably classlib experts could provide better way to fix this problem.
--
Artem Aliev, Intel Middleware Products Division
--- modules/luni/src/main/native/port/linux/hysock.c
+++ modules/luni/src/main/native/port/linux/hysock.c
@@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
I_32 rc = 0;
I_32 result = 0;
- result =
+ do
+ {
+ result =
select (nfds, readfds == NULL ? NULL : &readfds->handle,
writefds == NULL ? NULL : &writefds->handle,
exceptfds == NULL ? NULL : &exceptfds->handle,
timeout == NULL ? NULL : &timeout->time);
+ }
+ while (result == -1 && errno == EINTR);
+
if (result == -1)
{
rc = errno;
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Rana Dasgupta wrote:
> On 8/22/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> >According to Geir the snapshot from last week lasted just one minute
>> more
>> :)
>>
>> >It exception is the same, time is the same, then what is the difference?
>
>
> I most likely misread. I thought that Geir was saying that with the TM
> patch
> the exception is raised instantly and repeats. Without the TM patch, it
> happens after an hour both with last week's snapshot and with the current
> SVN head.
So I've retried with a clean build, and then the new 1.2M patch from
Salikh (that impressively does apply cleanly) and both result in the
same - the failure I reported w/o 10 seconds of start up with tomcat.
I think the thing to do here is :
1) really hope that someone can reproduce it tonight
2) check the pile in tomorrow and force us to fix it ASAP
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by Rana Dasgupta <rd...@gmail.com>.
On 8/22/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> >According to Geir the snapshot from last week lasted just one minute more
> :)
>
> >It exception is the same, time is the same, then what is the difference?
I most likely misread. I thought that Geir was saying that with the TM patch
the exception is raised instantly and repeats. Without the TM patch, it
happens after an hour both with last week's snapshot and with the current
SVN head.
Re: [drlvm] problem when TM patch applied
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 23 August 2006 02:35 Rana Dasgupta wrote:
> On 8/22/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >it also exhibited the same problem on Ubuntu 5 running in Parallels on a
> > >mac.
> > >
> > >the tgz can be found here :
> >
> > http://people.apache.org/~geirm/incubator-harmony-jre-r433739-linux-x86-3
> >2-snapshot
> >
> > >.tar.gz
> > >
> > >if someone wants to try it on some other linux...
>
> It may not be the same problem as the 1 hour 11 minute problem with last
> week's distribution, even if the exception is the same. (I saw bugs in the
> Tomcat database related to accept timeouts leading to similar
> exceptions over time) . I can try to start up and keep it running on W2003.
>
> If this is not Ubuntu specific and it is so immediate, we probabay should
> not commit till we know what's going on.
According to Geir the snapshot from last week lasted just one minute more :)
It exception is the same, time is the same, then what is the difference?
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Rana Dasgupta wrote:
> On 8/22/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> >it also exhibited the same problem on Ubuntu 5 running in Parallels on a
>> >mac.
>>
>> >the tgz can be found here :
>>
>> >
>> http://people.apache.org/~geirm/incubator-harmony-jre-r433739-linux-x86-32-snapshot
>>
>> >.tar.gz
>>
>> >if someone wants to try it on some other linux...
>
>
> It may not be the same problem as the 1 hour 11 minute problem with last
> week's distribution, even if the exception is the same. (I saw bugs in the
> Tomcat database related to accept timeouts leading to similar
> exceptions over time) . I can try to start up and keep it running on W2003.
>
> If this is not Ubuntu specific and it is so immediate, we probabay should
> not commit till we know what's going on.
Maybe - The nice thing about commiting is that it will force us to focus
on it right now, rather than put it off...
:)
geir
>
> Rana
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by Rana Dasgupta <rd...@gmail.com>.
On 8/22/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> >it also exhibited the same problem on Ubuntu 5 running in Parallels on a
> >mac.
>
> >the tgz can be found here :
>
> >
> http://people.apache.org/~geirm/incubator-harmony-jre-r433739-linux-x86-32-snapshot
> >.tar.gz
>
> >if someone wants to try it on some other linux...
It may not be the same problem as the 1 hour 11 minute problem with last
week's distribution, even if the exception is the same. (I saw bugs in the
Tomcat database related to accept timeouts leading to similar
exceptions over time) . I can try to start up and keep it running on W2003.
If this is not Ubuntu specific and it is so immediate, we probabay should
not commit till we know what's going on.
Rana
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
it also exhibited the same problem on Ubuntu 5 running in Parallels on a
mac.
the tgz can be found here :
http://people.apache.org/~geirm/incubator-harmony-jre-r433739-linux-x86-32-snapshot.tar.gz
if someone wants to try it on some other linux...
geir
Geir Magnusson Jr. wrote:
> Gregory Shimansky wrote:
>> On Wednesday 23 August 2006 00:29 Geir Magnusson Jr. wrote:
>>> Ok, with the snapshot from last week, I see the same problem in 1 hour,
>>> 12 minutes...
>>>
>>> Hmm...
>>>
>>> Ok, so I figure the thing to do is just commit it and we face the
>>> problem head on...
>>
>> It looks like there is a race condition somewhere. It is either
>> classlib or VM. To make it reproducible by others I just want to make
>> it clear about the workload executed which lead to socket exception.
>>
>> Did you just start Tomcat and let working idle with no requests?
>
> At the time that it crashed, for each of them, yes, there was no
> workload. I'm going to move to Unbuntu 5 and see if there is a difference.
>
> For last week snapshot, and current SVN, it took an hour and 11 min. I
> had , at startup, hit the tomcat home page and ran a servlet, but that
> was w/in the first minute of running
>
> After that, I just let it sit there.
>
> With the TM patch, it happens instantly, and loops on the same exception :
>
> Aug 22, 2006 4:52:43 PM INFO org.apache.catalina.startup.Catalina.start:
> Server startup in 4663 ms
> Aug 22, 2006 4:52:43 PM SEVERE
> org.apache.catalina.core.StandardServer.await: StandardServer.await:
> accept:
> Throwable occurred: java.net.SocketException: Interrupted system call
> at
> org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocketImpl(OSNetworkSystem.java)
>
> at
> org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocket(OSNetworkSystem.java:220)
>
> at
> org.apache.harmony.luni.net.PlainSocketImpl.accept(PlainSocketImpl.java:94)
> at java.net.ServerSocket.implAccept(ServerSocket.java:252)
> at java.net.ServerSocket.accept(ServerSocket.java:140)
> at
> org.apache.catalina.core.StandardServer.await(StandardServer.java:388)
> at org.apache.catalina.startup.Catalina.await(Catalina.java:615)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:575)
> at java.lang.reflect.VMReflection.invokeMethod()
> at java.lang.reflect.Method.invoke()
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
> Aug 22, 2006 4:52:43 PM WARNING
> org.apache.jk.common.ChannelSocket.acceptConnections: Exception
> executing accept
> Throwable occurred: java.lang.IllegalStateException:
> at java.util.zip.ZipFile.getEntryImpl(ZipFile.java)
> at java.util.zip.ZipFile.getEntry(ZipFile.java)
> at java.util.jar.JarFile.getEntry(JarFile.java)
> at java.util.jar.JarFile.getJarEntry(JarFile.java)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1020)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:617)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:616)
> at java.security.AccessController.doPrivilegedImpl()
> at java.security.AccessController.doPrivileged()
> at java.net.URLClassLoader.findClass(URLClassLoader.java:614)
> at java.lang.ClassLoader.loadClass()
> at
> java.net.URLClassLoader$SubURLClassLoader.loadClass(URLClassLoader.java:116)
>
> at java.lang.ClassLoader.loadClass()
> at java.lang.ClassLoader.loadClass()
> at java.lang.ClassLoader.loadClass()
> at java.lang.ClassLoader.loadClass()
> at java.lang.ClassLoader.loadClass()
> at
> org.apache.tomcat.util.buf.C2BConverter.<init>(C2BConverter.java:53)
> at org.apache.jk.core.MsgContext.<init>(MsgContext.java:84)
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> On Wednesday 23 August 2006 00:29 Geir Magnusson Jr. wrote:
>> Ok, with the snapshot from last week, I see the same problem in 1 hour,
>> 12 minutes...
>>
>> Hmm...
>>
>> Ok, so I figure the thing to do is just commit it and we face the
>> problem head on...
>
> It looks like there is a race condition somewhere. It is either classlib or
> VM. To make it reproducible by others I just want to make it clear about the
> workload executed which lead to socket exception.
>
> Did you just start Tomcat and let working idle with no requests?
At the time that it crashed, for each of them, yes, there was no
workload. I'm going to move to Unbuntu 5 and see if there is a difference.
For last week snapshot, and current SVN, it took an hour and 11 min. I
had , at startup, hit the tomcat home page and ran a servlet, but that
was w/in the first minute of running
After that, I just let it sit there.
With the TM patch, it happens instantly, and loops on the same exception :
Aug 22, 2006 4:52:43 PM INFO org.apache.catalina.startup.Catalina.start:
Server startup in 4663 ms
Aug 22, 2006 4:52:43 PM SEVERE
org.apache.catalina.core.StandardServer.await: StandardServer.await:
accept:
Throwable occurred: java.net.SocketException: Interrupted system call
at
org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocketImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocket(OSNetworkSystem.java:220)
at
org.apache.harmony.luni.net.PlainSocketImpl.accept(PlainSocketImpl.java:94)
at java.net.ServerSocket.implAccept(ServerSocket.java:252)
at java.net.ServerSocket.accept(ServerSocket.java:140)
at
org.apache.catalina.core.StandardServer.await(StandardServer.java:388)
at org.apache.catalina.startup.Catalina.await(Catalina.java:615)
at org.apache.catalina.startup.Catalina.start(Catalina.java:575)
at java.lang.reflect.VMReflection.invokeMethod()
at java.lang.reflect.Method.invoke()
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
Aug 22, 2006 4:52:43 PM WARNING
org.apache.jk.common.ChannelSocket.acceptConnections: Exception
executing accept
Throwable occurred: java.lang.IllegalStateException:
at java.util.zip.ZipFile.getEntryImpl(ZipFile.java)
at java.util.zip.ZipFile.getEntry(ZipFile.java)
at java.util.jar.JarFile.getEntry(JarFile.java)
at java.util.jar.JarFile.getJarEntry(JarFile.java)
at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1020)
at java.net.URLClassLoader$4.run(URLClassLoader.java:617)
at java.net.URLClassLoader$4.run(URLClassLoader.java:616)
at java.security.AccessController.doPrivilegedImpl()
at java.security.AccessController.doPrivileged()
at java.net.URLClassLoader.findClass(URLClassLoader.java:614)
at java.lang.ClassLoader.loadClass()
at
java.net.URLClassLoader$SubURLClassLoader.loadClass(URLClassLoader.java:116)
at java.lang.ClassLoader.loadClass()
at java.lang.ClassLoader.loadClass()
at java.lang.ClassLoader.loadClass()
at java.lang.ClassLoader.loadClass()
at java.lang.ClassLoader.loadClass()
at
org.apache.tomcat.util.buf.C2BConverter.<init>(C2BConverter.java:53)
at org.apache.jk.core.MsgContext.<init>(MsgContext.java:84)
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 23 August 2006 00:29 Geir Magnusson Jr. wrote:
> Ok, with the snapshot from last week, I see the same problem in 1 hour,
> 12 minutes...
>
> Hmm...
>
> Ok, so I figure the thing to do is just commit it and we face the
> problem head on...
It looks like there is a race condition somewhere. It is either classlib or
VM. To make it reproducible by others I just want to make it clear about the
workload executed which lead to socket exception.
Did you just start Tomcat and let working idle with no requests?
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Ok, with the snapshot from last week, I see the same problem in 1 hour,
12 minutes...
Hmm...
Ok, so I figure the thing to do is just commit it and we face the
problem head on...
geir
Geir Magnusson Jr. wrote:
> Andrey Chernyshev wrote:
>> On 8/22/06, Geir Magnusson Jr. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 8/22/06, Geir Magnusson Jr. <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] problem when TM patch applied
Posted by Andrey Chernyshev <a....@gmail.com>.
On 8/22/06, Geir Magnusson Jr. <ge...@pobox.com> 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'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?
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org