| View previous topic :: View next topic |
| Author |
Message |
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
 Posted: Mon Aug 30, 2004 6:52 pm Post subject: Server Mysteriously Exits |
 |
|
So I'm using the XmlRpcServlet I've programmed, but I'm having some issues interfacing with it using a java client. Here's a code snippet:
| Code: |
public class XmlRpcServlet : MethodServlet
{
protected Logger logger;
public this(Logger logger)
{
this.logger = logger;
}
public override void doPost (IServletRequest request, IServletResponse response)
{
response.setContentType("text/xml");
logger.trace("XML-RPC Server: got post");
|
Now, when I run the server using the following code:
| Code: | //The local port to bind to
InternetAddress bindTo = new InternetAddress(8181);
//The ServletProvider
ServletProvider sp = new ServletProvider();
//This is the nnServer in servlet form
NNServlet nnServlet = new NNServlet(hLogger);
nnServlet.install(sp);
//The HTTP Server
HttpServer httpServer = new HttpServer(sp, bindTo, 1, hLogger);
//Go!
httpServer.start();
|
(Where NNServlet extends XmlRpcServlet, but doesn't override the doPost or any other method)
Now, here's the pertinent console output:
| Quote: | INFO HTTP Server - Server http::Servlet started on 0.0.0.0:8181 with 1 accept threads, 10 backlogs
Killed
|
And it exits. You'll notice that my XML-RPC trace message is never displayed- so I know my code isn't causing this.
It does this right after the java client connects and sends the following ( I grabbed it using Ethereal)
| Quote: | POST /RPC2 HTTP/1.1
Content-Length: 157
Content-Type: text/xml
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.4.2_05
Host: localhost:8181
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
<?xml version="1.0" encoding="ISO-8859-1"?><methodCall><methodName>nnCore.getNode</methodName><params><param><value>1@1</value></param></params></methodCall>
|
I'm running svn revision 716 (HEAD at time of writing) on Linux. With previous versions, an exception (on the server side) was thrown saying something like "not enough data in stream" however this has been replaced with this random exit.
Any ideas?
Thanks
John |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 7:02 pm Post subject: |
|
|
I'll try this out myself. In the meantime, can you wrap a try/catch around everything to see what's barfing?
Also, can you maybe sprinkle a couple of printf calls around? I'll get back to you soon. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 7:29 pm Post subject: |
|
|
What you are seeing is a stack overflow. It happens because this function:
override IWriter write (void *x)
{
// do some stuff
super.write (x);
// do more stuff
}
does not call the superclass method at all; instead it calls itself, directly! The compiler is borked. I can patch this particular one, but there's quite a lot of super.x calls throughout Mango, especially in the HTTP-server arena due to all the glue methods required to get around Interface issues.
I'll report it and get back to you ... |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Aug 30, 2004 7:41 pm Post subject: |
|
|
*Sigh*
Is there any hope for D? |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 7:51 pm Post subject: |
|
|
Bug report posted to the NG, and directly to Walter. With luck, he'll provide access to a prior (working) version of the compiler. Unless someone has the zipfile for a prior version?
BTW; it breaks on Win32 also. |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Mon Aug 30, 2004 7:56 pm Post subject: |
|
|
Which one?
I've got:
0.98
0.97
0.95
0.93
If you want, I can sent it to you. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 7:58 pm Post subject: |
|
|
| can you send me v0.98 for windows? I'll try that one out ... (afraid I still don't have a linux box) |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Mon Aug 30, 2004 8:08 pm Post subject: Still got a problem |
|
|
OK... so I've gone back to 0.98, and there's no longer a stack overflow. It's back to the old issue... here's a transcript of the HTTP session:
| Code: | POST /RPC2 HTTP/1.1
Content-Length: 157
Content-Type: text/xml
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.4.2_05
Host: localhost:8181
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive |
Gets sent to the server, then the server sends back
| Code: | HTTP/1.1 200 OK
Content-Type:text/xml
Content-Length:289
Connection:close
<?xml version="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultString</name>
<value>
<string>Error: not enough data in stream</string>
</value>
</member>
<member>
<name>faultCode</name>
<value>
<int>-32400</int>
</value>
</member>
</struct>
</value>
</fault>
</methodResponse> |
Then, the client finishes it's send with:
| Code: | | <?xml version="1.0" encoding="ISO-8859-1"?><methodCall><methodName>nnCore.getNode</methodName><params><param><value>1@1</value></param></params></methodCall> |
The response is a result of my code: when an Exception is caught, it returnes that faultcode and the string "Error: " ~ e.toString(), with e being the exception.
For whatever reason, that exception is being thrown before the client even finishes sending it's request. This happens with two different Java HTTP clients.
Any idea why? |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 8:13 pm Post subject: |
|
|
Yeah; it's frustrating at times. I'd be pissed-off even if I were being paid ...  |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Mon Aug 30, 2004 8:27 pm Post subject: Another bug |
|
|
BTW, since I just ran into it (again) there's this bug where the program freezes after a certain number of requests. I can't ctrl-c out of it, just have to send it a SIGKILL. Dunno how many requests it takes. Dunno if it's OS specific.
This one's not a "show-stopper" like the other one is- well, it's not yet. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Aug 30, 2004 8:59 pm Post subject: |
|
|
| Well, Kris, it appears you still have some influence on Big W. Hopefully dmd 0.101 fixes some issues. Kudo's for the version fix, anyway. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 10:14 pm Post subject: Re: Still got a problem |
|
|
| demmegod wrote: |
OK... so I've gone back to 0.98, and there's no longer a stack overflow. It's back to the old issue... here's a transcript of the HTTP session:
| Code: | POST /RPC2 HTTP/1.1
Content-Length: 157
Content-Type: text/xml
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.4.2_05
Host: localhost:8181
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
|
Gets sent to the server, then the server sends back
| Code: | HTTP/1.1 200 OK
Content-Type:text/xml
Content-Length:289
Connection:close
<?xml version="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultString</name>
<value>
<string>Error: not enough data in stream</string>
</value>
</member>
<member>
<name>faultCode</name>
<value>
<int>-32400</int>
</value>
</member>
</struct>
</value>
</fault>
</methodResponse>
|
Then, the client finishes it's send with:
| Code: | <?xml version="1.0" encoding="ISO-8859-1"?><methodCall><methodName>nnCore.getNode</methodName><params><param><value>1@1</value></param></params></methodCall>
|
The response is a result of my code: when an Exception is caught, it returnes that faultcode and the string "Error: " ~ e.toString(), with e being the exception.
For whatever reason, that exception is being thrown before the client even finishes sending it's request. This happens with two different Java HTTP clients.
Any idea why?
|
 v0.101 seems to have fixed the super.() calls
that error message "not enough data in stream" does not exist in Mango, so I'm a bit perplexed. Can you try to identify which method call is causing the exception please? I mean, do you grab the content length value and then read the input stream?
The timing of this is interesting, since you point out that the server has already responded before the client sends the POST data; just shows how fast the Mango server really is 
Seriously though ~ the server will take action as soon as it has enough information to invoke a recipient. In this case, it accepted the socket request, mapped the request to your servlet, and executed the latter before the client finished sending the entire request. This is the expected behaviour, and the socket will remain open until the servlet returns.
This leads me to suspect the client is actually taking rather a long time to send the POST data. If, for example, your servlet is trying to read from the input stream and a timeout occurs, you might see this kind of behaviour. Mango supports read timeout on a socket, but it's turned off by default. I don't know if linux sets up a default by itself?
You might try the following: when your servlet gets control, grab the input Conduit, cast it to a SocketConduit, and call setTimeout(100000). You get the conduit via the following incantation:
| Code: |
request.getReader.getBuffer.getConduit(); |
We'll get to the bottom of this one soon enough!
Last edited by kris on Tue Aug 31, 2004 12:50 am; edited 4 times in total |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 10:16 pm Post subject: Re: Another bug |
|
|
| demmegod wrote: | BTW, since I just ran into it (again) there's this bug where the program freezes after a certain number of requests. I can't ctrl-c out of it, just have to send it a SIGKILL. Dunno how many requests it takes. Dunno if it's OS specific.
This one's not a "show-stopper" like the other one is- well, it's not yet. |
Bogus. I wonder if that's related to the socket woes which JJR saw on linux? Perhaps not. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 10:19 pm Post subject: |
|
|
| JJR wrote: | | Well, Kris, it appears you still have some influence on Big W. Hopefully dmd 0.101 fixes some issues. Kudo's for the version fix, anyway. |
I seriously doubt it! 
Good to see the 'out char[]' argument bug finally got fixed also. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Aug 30, 2004 10:20 pm Post subject: |
|
|
| Oh, I checked in the fixes for the new version= behaviour. Note that the makefiles have a small change to support that also. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
