| View previous topic :: View next topic |
| Author |
Message |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
 Posted: Mon Sep 06, 2004 7:53 pm Post subject: |
 |
|
| demmegod wrote: | | Quote: | | Let's have a look at the code ... oh yeah; there's an unimplemented linux method being used by the Ping servlet (I think JJR is gonna' fix that). If you download the latest SVN version of mango.example.Servlets and comment out line 569 (eliminate the Ping servlet), that should take care of the error. |
Didn't help. Still segfaults... same point according to gdb.
|
Turns out that the broken method is called from within a static class constructor, which (of course) gets invoked regardless of whether or not the class itself is instantiated. If you want to try it out, then comment out all the static constructor code starting at line 433 in mango.example.Servlets ... not that it's useful anymore. |
|
| Back to top |
|
 |
regan
Joined: 21 Jun 2004
Posts: 23
|
| Posted: Mon Sep 06, 2004 7:58 pm Post subject: |
|
|
| kris wrote: | | demmegod wrote: | Another thing (which is also mildly annoying) is that socket doesn't seem to close immediately when the program dies, so if I try to run it again without waiting about 60 seconds, I get the following:
| Code: | Unable to bind socket: Address already in use
socket cancel status now set
closing resource via destructor
closing socket handle ...
socket handle closed
|
This happens even when the program terminates "normally" and I only use the quotes because frequently after I hit enter, after the code in the main thread runs, I get a segfault. Not always, however |
That's life with sockets. They actually linger around for a while in the OS.
|
Does setting the 'do not linger' option before closing the socket change this?
| kris wrote: |
In this case, it's the listener socket on port 8181; when you restart the application, that port is still in use by the prior server-socket because the latter hasn't yet been cleaned up.
You can force the server-socket to grab the port by setting the "address reuse" flag on it. To do this, you should subclass HttpServer, override the createSocket() method, and make your version do the following:
| Code: | override ServerSocket createSocket (InternetAddress bind, int backlog)
{
return new ServerSocket (bind, backlog, true);
} |
Now your server-socket will reuse (the last argument) the port without question, even if it's still "in use" by another socket.
(perhaps there should be an easier way to do this)
- Kris |
I think so, either a defaulted parameter to the 'bind'? call or a seperate method you can call before doing the 'bind'.. I haven't looked closely at the code structure you already have so these are blind suggestions. |
|
| Back to top |
|
|
regan
Joined: 21 Jun 2004
Posts: 23
|
|
| Back to top |
|
|
regan
Joined: 21 Jun 2004
Posts: 23
|
| Posted: Mon Sep 06, 2004 8:11 pm Post subject: |
|
|
Ben just posted in the main NG that "std.thread installs SIGUSER1 and SIGUSER2 handlers for thread pausing and resuming."
So, what that means is if any thread gets a SIGUSER1 it will pause until it gets a SIGUSER2, right?
So something has sent the main thread a SIGUSER1.
Can you send it a SIGUSER2, that would confirm the problem is what I think it is.
Then we have to work out where the SIGUSER1 came from. |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Mon Sep 06, 2004 8:56 pm Post subject: |
|
|
| Sending either SIGUSR2 or 1 doesn't do anything. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Sep 06, 2004 9:18 pm Post subject: |
|
|
| regan wrote: | | kris wrote: | | demmegod wrote: | Another thing (which is also mildly annoying) is that socket doesn't seem to close immediately when the program dies, so if I try to run it again without waiting about 60 seconds, I get the following:
| Code: | Unable to bind socket: Address already in use
socket cancel status now set
closing resource via destructor
closing socket handle ...
socket handle closed
|
This happens even when the program terminates "normally" and I only use the quotes because frequently after I hit enter, after the code in the main thread runs, I get a segfault. Not always, however |
That's life with sockets. They actually linger around for a while in the OS.
|
Does setting the 'do not linger' option before closing the socket change this? |
Yes it does, but it's appears somewhat dependent upon the socket implementation as to how much of an effect that has. JJR tried this on linux in the past.
| regan wrote: | | kris wrote: |
In this case, it's the listener socket on port 8181; when you restart the application, that port is still in use by the prior server-socket because the latter hasn't yet been cleaned up.
You can force the server-socket to grab the port by setting the "address reuse" flag on it. To do this, you should subclass HttpServer, override the createSocket() method, and make your version do the following:
| Code: | override ServerSocket createSocket (InternetAddress bind, int backlog)
{
return new ServerSocket (bind, backlog, true);
} |
Now your server-socket will reuse (the last argument) the port without question, even if it's still "in use" by another socket.
(perhaps there should be an easier way to do this)
- Kris |
I think so, either a defaulted parameter to the 'bind'? call or a seperate method you can call before doing the 'bind'.. I haven't looked closely at the code structure you already have so these are blind suggestions. |
You have to get the "address reuse" flag set before binding; which is why it's part of the ServerSocket constructor. There's a number of approaches that would open this up; just a question of choosing an appropriate one, I think ... |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Sep 06, 2004 10:21 pm Post subject: |
|
|
| demmegod wrote: | | Sending either SIGUSR2 or 1 doesn't do anything. |
You might do a grep on your code-base, looking for a call to pause(). It's a long shot, but worth a try.
When you get a debugger going that can set a breakpoint, set one on Thread.pause() and try to catch who's invoking that. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Sep 06, 2004 10:36 pm Post subject: |
|
|
| demmegod wrote: | | This happens even when the program terminates "normally" and I only use the quotes because frequently after I hit enter, after the code in the main thread runs, I get a segfault. Not always, however. |
Cool! (sort of). You're also running into the same issue that JJR was. My I ask that you try to snapshot that one with strace, please? Would be really helpful to have a trace of that segv ... |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Tue Sep 07, 2004 1:58 pm Post subject: |
|
|
| Quote: | | You might do a grep on your code-base, looking for a call to pause(). It's a long shot, but worth a try. |
It was a longshot, and it didn't turn up anything.
| Quote: | | When you get a debugger going that can set a breakpoint, set one on Thread.pause() and try to catch who's invoking that. |
When is more like if. Normally, I'd just edit Thread.pause to put in a printf and a stacktrace, but as far as I know there's no (easy) way to get a stack trace.
So once Walter (or someone equally knowledgeable) gets back to me on the NG, I'll try disabling the GC. Other than that, what's my next move to try to get this working? |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Tue Sep 07, 2004 8:06 pm Post subject: |
|
|
| demmegod wrote: | | Quote: | | You might do a grep on your code-base, looking for a call to pause(). It's a long shot, but worth a try. |
It was a longshot, and it didn't turn up anything.
| Quote: | | When you get a debugger going that can set a breakpoint, set one on Thread.pause() and try to catch who's invoking that. |
When is more like if. Normally, I'd just edit Thread.pause to put in a printf and a stacktrace, but as far as I know there's no (easy) way to get a stack trace.
So once Walter (or someone equally knowledgeable) gets back to me on the NG, I'll try disabling the GC. Other than that, what's my next move to try to get this working? |
If it were my project, I'd isolate each granular chunk, one at a time. You've already done that with Mango, in that you can happily return "canned" responses to the client. You say it seems to work fine at that level, although such an observation doesn't rule out Mango entirely as a culprit.
Another big chunk you might test in isolation is your Xml-Rpc stuff. Write a little test jig that shoves data into the code, and accepts the response. Call it a million or so times and, if it passes, then it's less likely to be the culprit by itself.
Before doing that, you might isolate the XML parser by pumping example data through it also. Use the data that is produced by the client (the stuff that breaks the whole enchilada).
It may well turn out to be a combination of things; it may turn out to be Mango; or the XML layer; or the Xml-Rpc layer; or perhaps the compiler, GC & Phobos. Unfortunately, there's no magic bullet for these kinds of issues ~ one just has to be methodical and somewhat patient. Believe me, I've done plenty of that with the compiler during the construction of Mango 
As for testing Mango itself: I tend to beat the crap out of the particular layers that you're working with, and occasionally throw a few millions requests through the HTTP server. That doesn't mean it's bulletproof, but it has had the benefit of being roughed up ... I find that tends to shake out the glaring issues, and is why I'm suggesting you might try that with the other chunks of code also.
The one thing I would do, for sure, is to get it onto a debugger. MS has a free debugger somewhere on their web-site. I've used MSVC v6.0 for all of Mango thus far, and it works pretty well. At least you can set a breakpoint and trace the stack back through the source.
Another thing to consider: testing the code on a windows box may show completely different behaviour. Heck, it may even just work! I can categorically state that Mango has not been tested under linux to the same degree as it has under Windows. Besides, we already know there's some bizarre problem during shutdown, in addition to running out of sockets if one eats them up too quickly (much faster than you are, though).
- Kris |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Sat Sep 11, 2004 1:47 pm Post subject: Little Progress |
|
|
OK... I've been able to narrow the problem down to one of my libraries... This library does the database storage, and it uses std.stream to do so. I have a sneaky suspicion that std.stream is somehow conflicting with Mango.... what are the chances of this?
I've been meaning to convert it from std.stream to mango, so I guess I'll do that now to see if it helps. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
