This ticket http://jira.codehaus.org/browse/JRUBY-1460 is the only remaining problem with the JRuby mongrel port.
Anyone have any thoughts? Thanks for all the assistance so far. Evan On 10/18/07, Evan Weaver <[EMAIL PROTECTED]> wrote: > Ok, couple of things. > > Errno::ECONNABORTED doesn't exist on JRuby. This issue was already > known. http://jira.codehaus.org/browse/JRUBY-1393 > > Setting the priority of a dead thread causes a NPE. On MRI, it sets. > http://jira.codehaus.org/browse/JRUBY-1447 > > Evan > > > On 10/18/07, Evan Weaver <[EMAIL PROTECTED]> wrote: > > Well, not exactly synchronous, but more synchronous, at least. > > > > On 10/18/07, Evan Weaver <[EMAIL PROTECTED]> wrote: > > > 1. Ah, I see. Try mongrel trunk again; it's synchronous now. I don't > > > really see why it wasn't before, since a server can only have one > > > @acceptor anyway. > > > > > > What kind of system were you getting the error on, since I can't > > > reproduce it myself? > > > > > > 2. Filed, as you are probably aware. > > > > > > 3 & 4; still working. > > > > > > Evan > > > > > > On 10/18/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > > > > Evan Weaver wrote: > > > > > All right, here goes: > > > > > > > > > > 1. I can't reproduce this. Is the problem that closing the acceptor > > > > > thread doesn't block on JRuby? Or is it that the thread dies, but the > > > > > system still takes a few moments to release the socket? > > > > > > > > There are multiple layers of threads here. First off, the acceptor > > > > thread must be killed from outside. That's accomplished asynchronously > > > > in the HttpServer#stop call, as follows: > > > > > > > > def stop > > > > stopper = Thread.new do > > > > exc = StopServer.new > > > > @acceptor.raise(exc) > > > > end > > > > stopper.priority = 10 > > > > end > > > > > > > > There's no guarantee when this thread will run, even with a high > > > > priority. Since execution continues in the calling thread (the one > > > > running test_configurator) the calling thread's attempt to make a > > > > connection could succeed (if the raise call hasn't been reached yet), be > > > > connecting and then fail unexpectedly (if the acceptor is in the midst > > > > of raising), or fail outright (if the raise has completed successfully > > > > and the thread has terminated). > > > > > > > > At any rate, the call to stop is certainly not guaranteed to kill the > > > > target server before it returns. > > > > > > > > This one will vary from machine to machine depending on speed, number of > > > > cores, and OS-level threading characteristics, but I'm positive the test > > > > is not thread-safe. > > > > > > > > > 2. FileUtils#mkdir_p causes test suites to not register if the mkdir_p > > > > > argument already exists. Easily worked around but seems like a bug. > > > > > Here's a minimal example: > > > > > > > > > > require 'test/unit' > > > > > require 'fileutils' > > > > > FileUtils.mkdir_p "some_dir" > > > > > > > > > > class TrueTest < Test::Unit::TestCase > > > > > def test_true; assert true; end > > > > > end > > > > > > > > > > It works as long as "some_dir" doesn't already exist, mkdir_p is not > > > > > called, or mkdir_p is called from within a TrueTest instance method > > > > > rather than at load time. > > > > > > > > That's really weird, but it matches my observation. Can you file this as > > > > a bug in JIRA along with this simple test case? > > > > > > > > http://jira.codehaus.org/browse/JRUBY > > > > > > > > > 3. You have my JDK versions already... any more tips on how to debug > > > > > this? I'm using a 32bit system, for what it's worth. > > > > > > > > puts? > > > > > > > > Debugging this stuff is still a little difficult. Hopefully jruby-debug > > > > will come along soon. > > > > > > > > > 4. HttpServer is in the Mongrel module, so somehow it's not finding > > > > > that reference appropriately. I haven't looked at this in detail yet. > > > > > > > > This also could be a bug. If you look into it and can confirm it, file > > > > it in JIRA. > > > > > > > > - Charlie > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe from this list please visit: > > > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > > > > > > -- > > > Evan Weaver > > > Cloudburst, LLC > > > > > > > > > -- > > Evan Weaver > > Cloudburst, LLC > > > > > -- > Evan Weaver > Cloudburst, LLC > -- Evan Weaver Cloudburst, LLC --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
