500 error on VB WebService and Axis 1.1

[Matthias Lilke]

Hi!
I am deploying a VB WebService in turn running a FoxPro DLL. On the other
side, a Java App using Axis 1.1 requests information.
Once or twice a week the service stops responding. Restarting the IIS
doesn't help, the whole box needs to be restarted. I found nothing in the
event log. The only clues I have are from the web server log. There is
nothing out of the ordinary. c-ip and s-ip are always the same, the request
always goes to the same asmx. The only difference is the return code (and
the bytes transmitted).
I'm not dot net crack, adding event log capabilites or something along those
lines are an absolute very, very last resort. Is there a way to get an error
log similar to an apache or tomcat?
Funny thing is, the Java people tell me they connect via SOAP, the web log
tells me the connections use POST. Is that normal?
Thanks in advance!
Matt

 

[Dino Chiesa [Microsoft]]

Hi!
I am deploying a VB WebService in turn running a FoxPro DLL. On the other
side, a Java App using Axis 1.1 requests information.

I don't know anything about FoxPro.

Once or twice a week the service stops responding. Restarting the IIS
doesn't help, the whole box needs to be restarted. I found nothing in the
event log. The only clues I have are from the web server log. There is
nothing out of the ordinary. c-ip and s-ip are always the same, the request
always goes to the same asmx. The only difference is the return code (and
the bytes transmitted).

a 500 error is an app error on the server side. Have you crashed ASP.NET ?
Is there possibly a memory leak?

I'm not dot net crack, adding event log capabilites or something along those
lines are an absolute very, very last resort. Is there a way to get an error
log similar to an apache or tomcat?

you could add a SoapExtension to do tracing to a file. Google for
SoapExtension and you will find beaucoup examples.

Funny thing is, the Java people tell me they connect via SOAP, the web log
tells me the connections use POST. Is that normal?

No. The log is probably right.

 

[Matthias Lilke]

I don't know anything about FoxPro.

I don'T think the Fox is guilty of anything, just wanted to clarify that
FoxPro writes the XML not .net.

a 500 error is an app error on the server side. Have you crashed ASP.NET ?
Is there possibly a memory leak?

I do indeed think aspwp.exe crashed. The question is why! The job runs
on an half hour schedule´, transmitting about 30 requests. The
webservice server is dedicated to this one task (its a P4 1.7) so I
don't think we're talking about a too heavy work load either. The 500
error just comes sometimes an goes away after a few requests, but mostly
the 500 message go on indefinately until the machine is restarted.
Restarting just the IIS doesn't help either. That does point to asp.net.
I don't see an 'application hung' or anything like that in the eventlog
however. We are investigating the possibility of a memoryleak, but the
service runs for weeks at a time without a hitch, then it crashes twice
in one day.

you could add a SoapExtension to do tracing to a file. Google for
SoapExtension and you will find beaucoup examples.

I did find an article on msdn
(http://msdn.microsoft.com/library/d...bServicesProtocolsSoapExtensionClassTopic.asp)
unfortunately it assumes I'm a webservice crack! The example reads
great, but we still have to figure out how to call it during the process
and where.

No. The log is probably right.

In other words, instead of an ...80 POST /mis.asmx... I should be
getting a ...80 SOAP /mis.asmx... in the log file?
Thanks for your help thus far!! It's greatly appreciated!

 

[Patrice]

AFAIK, SOAP is a specification that describes the *content* of the HTTP
request. It 's normal to still see this as incoming HTTP requests (carrying
SOAP conforming *content*).

Nothing special in the IIS Log (do you see a 500 status code) ?. Nothing in
the Windows log ? You may want to add a global error handlder in your
webservice that would mail you encountered errors...

Patrice

 

[Dino Chiesa [Microsoft]]

if you have a memory leak in your asp.net app, and IIS (or ASP.neT) has
forcibly restarted the app, you will get an event in the computer's event
log. (Asp.NET has a feature where it will restart your app if it behaves
poorly).

You can also use Task Manager, or something more involved like perfmon, to
check or monitor memory usage and other metrics.

I agree the SoapTraceExtension is not a checkbox solution. In other words
you have to add code to your app. Once you get it running it is pretty
simple.

AFAIK, SOAP is a specification that describes the *content* of the HTTP
request. It 's normal to still see this as incoming HTTP requests (carrying
SOAP conforming *content*).

yes, .
ASP.NET supports, out of the box, 3 different modes for tickling
webservices: HttpPost, HttpGet, and HttpSoap. All use Http. You'll note
that As a result there is some unfortunate fuzziness and confusion about
POST versus SOAP versus HTTP. In actual fact if you are sending SOAP to an
ASMX endpoint, you are probably sending it via HTTP POST. So the HttpSoap
protocol name ought to be HttpPostSoap. Check this article for some
background on the issue.
http://msdn.microsoft.com/library/e...nconfigurationoptionsforaspnetwebservices.asp

So when the original poster said "they said they connect via SOAP but my
logs indicate POST", it is possible to be both.

 

[Matthias Lilke]

Hi Patrice,
thanks for clarifying the SOAP request thing. I thought SOAP was a
different kind of protocol...
I do get 500 errors in the web log but nothing I can find in Windows or
Eventlogs.
I was hinted to look for soap extension which I did and I found this
article
(http://msdn.microsoft.com/library/d...bServicesProtocolsSoapExtensionClassTopic.asp)
but I'm still trying to make heads and tails out of it.

 

[Matthias Lilke]

Thanks Dino,
I'm still working on the extension, but it'll get there! I can't find
anyting in the event log about IIS or aspwp restarting. The only thing I
have is the 500 in the IIS log.
I'm starting to think the DB connection is somehow at fault. If it is
lost, the FoxPro core of the WS crashes taking the WS along for the
ride. It would make sense that the IIS only recognizes the error as a
general 500.

 

[Dino Chiesa [Microsoft]]

you could try judiciously applying Try...Catch... clauses to find the
source of the error.
This will catch any exceptions and allow you to log an error, fire a trace
event, modify the response, or whatever.

Defensive programming !

-D

 

[Patrice]

It confirms you have an a runtime error in your service. Now you could add a
global errror handler so that each error is reported with its details (in a
usual app it can be done in global.asax).

Patrice