By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,611 Members | 1,642 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,611 IT Pros & Developers. It's quick & easy.

Web Service To No Where...

P: n/a


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?

Nov 23 '05 #1
Share this Question
Share on Google+
30 Replies


P: n/a
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #2

P: n/a
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #3

P: n/a

I would buy that explaination, except the web service server logs ( iis
) don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #4

P: n/a

I would buy that explaination, except the web service server logs ( iis
) don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #5

P: n/a

PS -- I also have tracing and logging on the web service -- those calls
are never recorded there.
Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #6

P: n/a

PS -- I also have tracing and logging on the web service -- those calls
are never recorded there.
Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #7

P: n/a
There is a client-side limit to how many simultaneous calls you can make
from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that the
calls are not dropped in the client side. You should see an exception in the
callback of the async call if the call is not completed.

Also, you could try debugging the problem by using your own threads to issue
the calls instead of using the built-in BeginXXX methods. This way you could
log every outgoing call and determine if and where the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...

I would buy that explaination, except the web service server logs ( iis )
don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is
the case with one-way Web services where the Web service is defined to
NOT return any value. In that case, the proxy sends the SOAP message and
closes the connection right away without waiting to see if SOAP Faults
are returned. Try to force your Web service to return some value (or
change the proxy generated file) and try again. You might start receiving
a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database
side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #8

P: n/a
There is a client-side limit to how many simultaneous calls you can make
from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that the
calls are not dropped in the client side. You should see an exception in the
callback of the async call if the call is not completed.

Also, you could try debugging the problem by using your own threads to issue
the calls instead of using the built-in BeginXXX methods. This way you could
log every outgoing call and determine if and where the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...

I would buy that explaination, except the web service server logs ( iis )
don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is
the case with one-way Web services where the Web service is defined to
NOT return any value. In that case, the proxy sends the SOAP message and
closes the connection right away without waiting to see if SOAP Faults
are returned. Try to force your Web service to return some value (or
change the proxy generated file) and try again. You might start receiving
a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database
side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #9

P: n/a
Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can make
from one AppDomain to one web service (see the
ServicePointManager.DefaultConnectionLimit property). Make sure that the
calls are not dropped in the client side. You should see an exception in
the callback of the async call if the call is not completed.
I wrap the Begin_ method in a try catch block. Is that enough? Or are you
saying there is a property of the IAsyncResult that I can access that traps
errors?
Also, you could try debugging the problem by using your own threads to
issue the calls instead of using the built-in BeginXXX methods. This way
you could log every outgoing call and determine if and where the calls are
dropped.
Wow! Ok, so I could launch the calls using the synchronized method, but,
say put them all into the ThreadPool?

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...

I would buy that explaination, except the web service server logs ( iis )
don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is
the case with one-way Web services where the Web service is defined to
NOT return any value. In that case, the proxy sends the SOAP message and
closes the connection right away without waiting to see if SOAP Faults
are returned. Try to force your Web service to return some value (or
change the proxy generated file) and try again. You might start
receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database
side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?



--
Texeme Textcasting Technology
http://www.texeme.com
Nov 23 '05 #10

P: n/a
Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can make
from one AppDomain to one web service (see the
ServicePointManager.DefaultConnectionLimit property). Make sure that the
calls are not dropped in the client side. You should see an exception in
the callback of the async call if the call is not completed.
I wrap the Begin_ method in a try catch block. Is that enough? Or are you
saying there is a property of the IAsyncResult that I can access that traps
errors?
Also, you could try debugging the problem by using your own threads to
issue the calls instead of using the built-in BeginXXX methods. This way
you could log every outgoing call and determine if and where the calls are
dropped.
Wow! Ok, so I could launch the calls using the synchronized method, but,
say put them all into the ThreadPool?

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...

I would buy that explaination, except the web service server logs ( iis )
don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is
the case with one-way Web services where the Web service is defined to
NOT return any value. In that case, the proxy sends the SOAP message and
closes the connection right away without waiting to see if SOAP Faults
are returned. Try to force your Web service to return some value (or
change the proxy generated file) and try again. You might start
receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database
side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?



--
Texeme Textcasting Technology
http://www.texeme.com
Nov 23 '05 #11

P: n/a
Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can make

Actually, it looks like the default is unlimited:

http://msdn.microsoft.com/library/de...rtiesTopic.asp
"Property Value

The maximum number of ServicePoint instances to maintain. The default
value is 0, which means there is no limit to the number of ServicePoint
instances."
I did take your advice below on putting the try/catch around the End__
method, and will test with that.

from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that the
calls are not dropped in the client side. You should see an exception in the
callback of the async call if the call is not completed.

Also, you could try debugging the problem by using your own threads to issue
the calls instead of using the built-in BeginXXX methods. This way you could
log every outgoing call and determine if and where the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...
I would buy that explaination, except the web service server logs ( iis )
don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is
the case with one-way Web services where the Web service is defined to
NOT return any value. In that case, the proxy sends the SOAP message and
closes the connection right away without waiting to see if SOAP Faults
are returned. Try to force your Web service to return some value (or
change the proxy generated file) and try again. You might start receiving
a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database
side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?



Nov 23 '05 #12

P: n/a
Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can make

Actually, it looks like the default is unlimited:

http://msdn.microsoft.com/library/de...rtiesTopic.asp
"Property Value

The maximum number of ServicePoint instances to maintain. The default
value is 0, which means there is no limit to the number of ServicePoint
instances."
I did take your advice below on putting the try/catch around the End__
method, and will test with that.

from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that the
calls are not dropped in the client side. You should see an exception in the
callback of the async call if the call is not completed.

Also, you could try debugging the problem by using your own threads to issue
the calls instead of using the built-in BeginXXX methods. This way you could
log every outgoing call and determine if and where the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...
I would buy that explaination, except the web service server logs ( iis )
don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is
the case with one-way Web services where the Web service is defined to
NOT return any value. In that case, the proxy sends the SOAP message and
closes the connection right away without waiting to see if SOAP Faults
are returned. Try to force your Web service to return some value (or
change the proxy generated file) and try again. You might start receiving
a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database
side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?



Nov 23 '05 #13

P: n/a

Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a file,
in quick succession. For 29 of those calls, the method threw this error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29 times
out of 380 when called asynchronously?

Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can make
from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that the
calls are not dropped in the client side. You should see an exception in the
callback of the async call if the call is not completed.

Also, you could try debugging the problem by using your own threads to issue
the calls instead of using the built-in BeginXXX methods. This way you could
log every outgoing call and determine if and where the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...
I would buy that explaination, except the web service server logs ( iis )
don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is
the case with one-way Web services where the Web service is defined to
NOT return any value. In that case, the proxy sends the SOAP message and
closes the connection right away without waiting to see if SOAP Faults
are returned. Try to force your Web service to return some value (or
change the proxy generated file) and try again. You might start receiving
a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database
side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?



Nov 23 '05 #14

P: n/a

Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a file,
in quick succession. For 29 of those calls, the method threw this error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29 times
out of 380 when called asynchronously?

Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can make
from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that the
calls are not dropped in the client side. You should see an exception in the
callback of the async call if the call is not completed.

Also, you could try debugging the problem by using your own threads to issue
the calls instead of using the built-in BeginXXX methods. This way you could
log every outgoing call and determine if and where the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...
I would buy that explaination, except the web service server logs ( iis )
don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is
the case with one-way Web services where the Web service is defined to
NOT return any value. In that case, the proxy sends the SOAP message and
closes the connection right away without waiting to see if SOAP Faults
are returned. Try to force your Web service to return some value (or
change the proxy generated file) and try again. You might start receiving
a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database
side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?



Nov 23 '05 #15

P: n/a

This might be an answer:

http://www.dotnet247.com/247referenc...43/219122.aspx

"I eventually found a couple KB article explaining this and the solution
(262635 - Error Message: HTTP 403.9 - Access Forbidden: Too Many Users Are
Connected, 308186 - HOW TO: Optimize Web Server Performance in Windows
2000). The keep-alives can be disabled through IIS admin interface. This
resolves my problem."

John Bailo wrote:

Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a file,
in quick succession. For 29 of those calls, the method threw this error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29 times
out of 380 when called asynchronously?

Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can
make from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that
the calls are not dropped in the client side. You should see an
exception in the callback of the async call if the call is not completed.

Also, you could try debugging the problem by using your own threads to
issue the calls instead of using the built-in BeginXXX methods. This
way you could log every outgoing call and determine if and where the
calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...
I would buy that explaination, except the web service server logs (
iis ) don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:

It could be that error messages are generated, but not received.
This is the case with one-way Web services where the Web service is
defined to NOT return any value. In that case, the proxy sends the
SOAP message and closes the connection right away without waiting to
see if SOAP Faults are returned. Try to force your Web service to
return some value (or change the proxy generated file) and try
again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

> I wrote a program that loops through a file of records.
>
> It parses each line in the file and sends them to a web service
> that inserts them into an AS400DB2 database using Asynch calls.
>
> This is the wierd part. Say their are 500 records in the file.
>
> If I run the process once, maybe 250 will appear.
>
> If I run it a second time, maybe 400 or all the records will appear.
>
> Usually the third time I run it, all 500 appear.
>
> From the consuming program, that reads the records, there is never
> any error message thrown. There are always 500 calls to the web
> service.
>
> I can see from my web server logs that the service is just not
> called when the records are not written, so I don't think its on
> the database side.
>
> So my question is: If they don't error out, where do all these web
> services calls go?? I ASP.NET webservices just that flawed and
> inconsistent that it cannot be depended on for this type of operation?
>
> Would a more robust web server such as Apache 2.0 help?
>
>
>
>
>
>


Nov 23 '05 #16

P: n/a

This might be an answer:

http://www.dotnet247.com/247referenc...43/219122.aspx

"I eventually found a couple KB article explaining this and the solution
(262635 - Error Message: HTTP 403.9 - Access Forbidden: Too Many Users Are
Connected, 308186 - HOW TO: Optimize Web Server Performance in Windows
2000). The keep-alives can be disabled through IIS admin interface. This
resolves my problem."

John Bailo wrote:

Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a file,
in quick succession. For 29 of those calls, the method threw this error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29 times
out of 380 when called asynchronously?

Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can
make from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that
the calls are not dropped in the client side. You should see an
exception in the callback of the async call if the call is not completed.

Also, you could try debugging the problem by using your own threads to
issue the calls instead of using the built-in BeginXXX methods. This
way you could log every outgoing call and determine if and where the
calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...
I would buy that explaination, except the web service server logs (
iis ) don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:

It could be that error messages are generated, but not received.
This is the case with one-way Web services where the Web service is
defined to NOT return any value. In that case, the proxy sends the
SOAP message and closes the connection right away without waiting to
see if SOAP Faults are returned. Try to force your Web service to
return some value (or change the proxy generated file) and try
again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

> I wrote a program that loops through a file of records.
>
> It parses each line in the file and sends them to a web service
> that inserts them into an AS400DB2 database using Asynch calls.
>
> This is the wierd part. Say their are 500 records in the file.
>
> If I run the process once, maybe 250 will appear.
>
> If I run it a second time, maybe 400 or all the records will appear.
>
> Usually the third time I run it, all 500 appear.
>
> From the consuming program, that reads the records, there is never
> any error message thrown. There are always 500 calls to the web
> service.
>
> I can see from my web server logs that the service is just not
> called when the records are not written, so I don't think its on
> the database side.
>
> So my question is: If they don't error out, where do all these web
> services calls go?? I ASP.NET webservices just that flawed and
> inconsistent that it cannot be depended on for this type of operation?
>
> Would a more robust web server such as Apache 2.0 help?
>
>
>
>
>
>


Nov 23 '05 #17

P: n/a

Well, maybe not.

I set the keep alives off and when I ran the program, it loaded 20
records and then locked up in studio without ever getting to a
breakpoint or error.

John Bailo wrote:

This might be an answer:

http://www.dotnet247.com/247referenc...43/219122.aspx

"I eventually found a couple KB article explaining this and the solution
(262635 - Error Message: HTTP 403.9 - Access Forbidden: Too Many Users Are
Connected, 308186 - HOW TO: Optimize Web Server Performance in Windows
2000). The keep-alives can be disabled through IIS admin interface. This
resolves my problem."

John Bailo wrote:

Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a
file, in quick succession. For 29 of those calls, the method threw
this error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29 times
out of 380 when called asynchronously?

Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can
make from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that
the calls are not dropped in the client side. You should see an
exception in the callback of the async call if the call is not
completed.

Also, you could try debugging the problem by using your own threads
to issue the calls instead of using the built-in BeginXXX methods.
This way you could log every outgoing call and determine if and where
the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...

I would buy that explaination, except the web service server logs (
iis ) don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:

> It could be that error messages are generated, but not received.
> This is the case with one-way Web services where the Web service is
> defined to NOT return any value. In that case, the proxy sends the
> SOAP message and closes the connection right away without waiting
> to see if SOAP Faults are returned. Try to force your Web service
> to return some value (or change the proxy generated file) and try
> again. You might start receiving a lot of errors.
>
> Waleed
>
>
> "ja*****@texeme.com" wrote:
>
>
>
>> I wrote a program that loops through a file of records.
>>
>> It parses each line in the file and sends them to a web service
>> that inserts them into an AS400DB2 database using Asynch calls.
>>
>> This is the wierd part. Say their are 500 records in the file.
>>
>> If I run the process once, maybe 250 will appear.
>>
>> If I run it a second time, maybe 400 or all the records will appear.
>>
>> Usually the third time I run it, all 500 appear.
>>
>> From the consuming program, that reads the records, there is never
>> any error message thrown. There are always 500 calls to the web
>> service.
>>
>> I can see from my web server logs that the service is just not
>> called when the records are not written, so I don't think its on
>> the database side.
>>
>> So my question is: If they don't error out, where do all these
>> web services calls go?? I ASP.NET webservices just that flawed
>> and inconsistent that it cannot be depended on for this type of
>> operation?
>>
>> Would a more robust web server such as Apache 2.0 help?
>>
>>
>>
>>
>>
>>

Nov 23 '05 #18

P: n/a

Well, maybe not.

I set the keep alives off and when I ran the program, it loaded 20
records and then locked up in studio without ever getting to a
breakpoint or error.

John Bailo wrote:

This might be an answer:

http://www.dotnet247.com/247referenc...43/219122.aspx

"I eventually found a couple KB article explaining this and the solution
(262635 - Error Message: HTTP 403.9 - Access Forbidden: Too Many Users Are
Connected, 308186 - HOW TO: Optimize Web Server Performance in Windows
2000). The keep-alives can be disabled through IIS admin interface. This
resolves my problem."

John Bailo wrote:

Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a
file, in quick succession. For 29 of those calls, the method threw
this error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29 times
out of 380 when called asynchronously?

Sami Vaaraniemi wrote:
There is a client-side limit to how many simultaneous calls you can
make from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure that
the calls are not dropped in the client side. You should see an
exception in the callback of the async call if the call is not
completed.

Also, you could try debugging the problem by using your own threads
to issue the calls instead of using the built-in BeginXXX methods.
This way you could log every outgoing call and determine if and where
the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...

I would buy that explaination, except the web service server logs (
iis ) don't show those missing calls.

So, where are those calls?

Waleed Abdulla xrules org> <waleed_abdulla wrote:

> It could be that error messages are generated, but not received.
> This is the case with one-way Web services where the Web service is
> defined to NOT return any value. In that case, the proxy sends the
> SOAP message and closes the connection right away without waiting
> to see if SOAP Faults are returned. Try to force your Web service
> to return some value (or change the proxy generated file) and try
> again. You might start receiving a lot of errors.
>
> Waleed
>
>
> "ja*****@texeme.com" wrote:
>
>
>
>> I wrote a program that loops through a file of records.
>>
>> It parses each line in the file and sends them to a web service
>> that inserts them into an AS400DB2 database using Asynch calls.
>>
>> This is the wierd part. Say their are 500 records in the file.
>>
>> If I run the process once, maybe 250 will appear.
>>
>> If I run it a second time, maybe 400 or all the records will appear.
>>
>> Usually the third time I run it, all 500 appear.
>>
>> From the consuming program, that reads the records, there is never
>> any error message thrown. There are always 500 calls to the web
>> service.
>>
>> I can see from my web server logs that the service is just not
>> called when the records are not written, so I don't think its on
>> the database side.
>>
>> So my question is: If they don't error out, where do all these
>> web services calls go?? I ASP.NET webservices just that flawed
>> and inconsistent that it cannot be depended on for this type of
>> operation?
>>
>> Would a more robust web server such as Apache 2.0 help?
>>
>>
>>
>>
>>
>>

Nov 23 '05 #19

P: n/a
Let me though in some more pointers to check:

1. Are you using SSL? If so, try without it and see if there is a
difference. SSL connections are typically left open longer to conserve
resources. If your web service can't establish an SSL connection, a Web
service request won't show in your server logs.

2. Could it be that the the processing on the server is slow, and your web
server is overwhelmved? If the IIS pipe is full, I suspect it will reject new
requests without passing them to .NET to be logged and processed.

3. When you say you're looking at the server logs, are you refering to the
..NET Web services logging feature or the IIS logs? If you're not checking the
IIS logs, check them to see if the number of requests matches the number of
requests in the .NET WS logs.

good luck,
Waleed
"ja*****@texeme.com" wrote:

PS -- I also have tracing and logging on the web service -- those calls
are never recorded there.
Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #20

P: n/a
Let me though in some more pointers to check:

1. Are you using SSL? If so, try without it and see if there is a
difference. SSL connections are typically left open longer to conserve
resources. If your web service can't establish an SSL connection, a Web
service request won't show in your server logs.

2. Could it be that the the processing on the server is slow, and your web
server is overwhelmved? If the IIS pipe is full, I suspect it will reject new
requests without passing them to .NET to be logged and processed.

3. When you say you're looking at the server logs, are you refering to the
..NET Web services logging feature or the IIS logs? If you're not checking the
IIS logs, check them to see if the number of requests matches the number of
requests in the .NET WS logs.

good luck,
Waleed
"ja*****@texeme.com" wrote:

PS -- I also have tracing and logging on the web service -- those calls
are never recorded there.
Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:


I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #21

P: n/a

More info. See article below.

So, what I think is:

My dev workstation is an XP Pro machine. I'm assuming that it has the
10 user limit ( which is great from a marketing perspective that M$ can
limit people from running an XP server, but sucks eggs as far as me, the
developer, wanting to benchtest a production web service locally!) The
article says that even if I disable the keep-lives, I still am up
against the 10 person limit....in fact, by disabling the keep alives, my
web service calls probably happen so fast they overwhelm the II5 server
on XP and thus the lock up decribed below ( possibly ).

So, my guess is the disabling of the Keep-Alives on my production web
server ( which is running 2k server ) may have the intended effect of
lessening the number of calls to the web service that return the 403.9
error.

We'll see!

http://support.microsoft.com/default...b;en-us;262635

Error Message: HTTP 403.9 - Access Forbidden: Too many users are connected

RESOLUTION
If more than ten connections are needed, use the version of IIS 5.0 that
is included in Windows 2000 Server.

If you use IIS 5.0 on Windows 2000 Professional or IIS 5.1 on Microsoft
Windows XP Professional, disable HTTP keep-alives in the properties of
the Web site. When you do this, a limit of 10 concurrent connections
still exists, but IIS does not maintain connections for inactive users.

John Bailo wrote:

Well, maybe not.

I set the keep alives off and when I ran the program, it loaded 20
records and then locked up in studio without ever getting to a
breakpoint or error.

John Bailo wrote:

This might be an answer:

http://www.dotnet247.com/247referenc...43/219122.aspx

"I eventually found a couple KB article explaining this and the solution
(262635 - Error Message: HTTP 403.9 - Access Forbidden: Too Many Users
Are
Connected, 308186 - HOW TO: Optimize Web Server Performance in Windows
2000). The keep-alives can be disabled through IIS admin interface. This
resolves my problem."

John Bailo wrote:

Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a
file, in quick succession. For 29 of those calls, the method threw
this error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29
times out of 380 when called asynchronously?

Sami Vaaraniemi wrote:

There is a client-side limit to how many simultaneous calls you can
make from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure
that the calls are not dropped in the client side. You should see an
exception in the callback of the async call if the call is not
completed.

Also, you could try debugging the problem by using your own threads
to issue the calls instead of using the built-in BeginXXX methods.
This way you could log every outgoing call and determine if and
where the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...

> I would buy that explaination, except the web service server logs (
> iis ) don't show those missing calls.
>
> So, where are those calls?
>
> Waleed Abdulla xrules org> <waleed_abdulla wrote:
>
>> It could be that error messages are generated, but not received.
>> This is the case with one-way Web services where the Web service
>> is defined to NOT return any value. In that case, the proxy sends
>> the SOAP message and closes the connection right away without
>> waiting to see if SOAP Faults are returned. Try to force your Web
>> service to return some value (or change the proxy generated file)
>> and try again. You might start receiving a lot of errors.
>>
>> Waleed
>>
>>
>> "ja*****@texeme.com" wrote:
>>
>>
>>
>>> I wrote a program that loops through a file of records.
>>>
>>> It parses each line in the file and sends them to a web service
>>> that inserts them into an AS400DB2 database using Asynch calls.
>>>
>>> This is the wierd part. Say their are 500 records in the file.
>>>
>>> If I run the process once, maybe 250 will appear.
>>>
>>> If I run it a second time, maybe 400 or all the records will appear.
>>>
>>> Usually the third time I run it, all 500 appear.
>>>
>>> From the consuming program, that reads the records, there is
>>> never any error message thrown. There are always 500 calls to
>>> the web service.
>>>
>>> I can see from my web server logs that the service is just not
>>> called when the records are not written, so I don't think its on
>>> the database side.
>>>
>>> So my question is: If they don't error out, where do all these
>>> web services calls go?? I ASP.NET webservices just that flawed
>>> and inconsistent that it cannot be depended on for this type of
>>> operation?
>>>
>>> Would a more robust web server such as Apache 2.0 help?
>>>
>>>
>>>
>>>
>>>
>>>

Nov 23 '05 #22

P: n/a

More info. See article below.

So, what I think is:

My dev workstation is an XP Pro machine. I'm assuming that it has the
10 user limit ( which is great from a marketing perspective that M$ can
limit people from running an XP server, but sucks eggs as far as me, the
developer, wanting to benchtest a production web service locally!) The
article says that even if I disable the keep-lives, I still am up
against the 10 person limit....in fact, by disabling the keep alives, my
web service calls probably happen so fast they overwhelm the II5 server
on XP and thus the lock up decribed below ( possibly ).

So, my guess is the disabling of the Keep-Alives on my production web
server ( which is running 2k server ) may have the intended effect of
lessening the number of calls to the web service that return the 403.9
error.

We'll see!

http://support.microsoft.com/default...b;en-us;262635

Error Message: HTTP 403.9 - Access Forbidden: Too many users are connected

RESOLUTION
If more than ten connections are needed, use the version of IIS 5.0 that
is included in Windows 2000 Server.

If you use IIS 5.0 on Windows 2000 Professional or IIS 5.1 on Microsoft
Windows XP Professional, disable HTTP keep-alives in the properties of
the Web site. When you do this, a limit of 10 concurrent connections
still exists, but IIS does not maintain connections for inactive users.

John Bailo wrote:

Well, maybe not.

I set the keep alives off and when I ran the program, it loaded 20
records and then locked up in studio without ever getting to a
breakpoint or error.

John Bailo wrote:

This might be an answer:

http://www.dotnet247.com/247referenc...43/219122.aspx

"I eventually found a couple KB article explaining this and the solution
(262635 - Error Message: HTTP 403.9 - Access Forbidden: Too Many Users
Are
Connected, 308186 - HOW TO: Optimize Web Server Performance in Windows
2000). The keep-alives can be disabled through IIS admin interface. This
resolves my problem."

John Bailo wrote:

Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a
file, in quick succession. For 29 of those calls, the method threw
this error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29
times out of 380 when called asynchronously?

Sami Vaaraniemi wrote:

There is a client-side limit to how many simultaneous calls you can
make from one AppDomain to one web service (see the
ServicePointManager.DefaultCon*nectionLimit property). Make sure
that the calls are not dropped in the client side. You should see an
exception in the callback of the async call if the call is not
completed.

Also, you could try debugging the problem by using your own threads
to issue the calls instead of using the built-in BeginXXX methods.
This way you could log every outgoing call and determine if and
where the calls are dropped.

Regards,
Sami

<ja*****@texeme.com> wrote in message
news:sJ********************@speakeasy.net...

> I would buy that explaination, except the web service server logs (
> iis ) don't show those missing calls.
>
> So, where are those calls?
>
> Waleed Abdulla xrules org> <waleed_abdulla wrote:
>
>> It could be that error messages are generated, but not received.
>> This is the case with one-way Web services where the Web service
>> is defined to NOT return any value. In that case, the proxy sends
>> the SOAP message and closes the connection right away without
>> waiting to see if SOAP Faults are returned. Try to force your Web
>> service to return some value (or change the proxy generated file)
>> and try again. You might start receiving a lot of errors.
>>
>> Waleed
>>
>>
>> "ja*****@texeme.com" wrote:
>>
>>
>>
>>> I wrote a program that loops through a file of records.
>>>
>>> It parses each line in the file and sends them to a web service
>>> that inserts them into an AS400DB2 database using Asynch calls.
>>>
>>> This is the wierd part. Say their are 500 records in the file.
>>>
>>> If I run the process once, maybe 250 will appear.
>>>
>>> If I run it a second time, maybe 400 or all the records will appear.
>>>
>>> Usually the third time I run it, all 500 appear.
>>>
>>> From the consuming program, that reads the records, there is
>>> never any error message thrown. There are always 500 calls to
>>> the web service.
>>>
>>> I can see from my web server logs that the service is just not
>>> called when the records are not written, so I don't think its on
>>> the database side.
>>>
>>> So my question is: If they don't error out, where do all these
>>> web services calls go?? I ASP.NET webservices just that flawed
>>> and inconsistent that it cannot be depended on for this type of
>>> operation?
>>>
>>> Would a more robust web server such as Apache 2.0 help?
>>>
>>>
>>>
>>>
>>>
>>>

Nov 23 '05 #23

P: n/a
Waleed Abdulla xrules org> <waleed_abdulla wrote:
Let me though in some more pointers to check:

1. Are you using SSL? If so, try without it and see if there is a
difference. SSL connections are typically left open longer to conserve
resources. If your web service can't establish an SSL connection, a Web
service request won't show in your server logs.
No SSL.

2. Could it be that the the processing on the server is slow, and your web
server is overwhelmved? If the IIS pipe is full, I suspect it will reject new
requests without passing them to .NET to be logged and processed.
Quite possibly. I thought it was a dual proc, but now looking via the
MMC is is single proc!

With the help of this group, at least I am now able to trap the error --
403 -- whereas before it just looked like the call was goings to "no
where" as the title of this thread says....
3. When you say you're looking at the server logs, are you refering to the
.NET Web services logging feature or the IIS logs? If you're not checking the
I am refering to the IIS logs.
IIS logs, check them to see if the number of requests matches the number of
requests in the .NET WS logs.
I wasn't aware of those! Where are they located?

good luck,
Waleed
"ja*****@texeme.com" wrote:

PS -- I also have tracing and logging on the web service -- those calls
are never recorded there.
Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #24

P: n/a
Waleed Abdulla xrules org> <waleed_abdulla wrote:
Let me though in some more pointers to check:

1. Are you using SSL? If so, try without it and see if there is a
difference. SSL connections are typically left open longer to conserve
resources. If your web service can't establish an SSL connection, a Web
service request won't show in your server logs.
No SSL.

2. Could it be that the the processing on the server is slow, and your web
server is overwhelmved? If the IIS pipe is full, I suspect it will reject new
requests without passing them to .NET to be logged and processed.
Quite possibly. I thought it was a dual proc, but now looking via the
MMC is is single proc!

With the help of this group, at least I am now able to trap the error --
403 -- whereas before it just looked like the call was goings to "no
where" as the title of this thread says....
3. When you say you're looking at the server logs, are you refering to the
.NET Web services logging feature or the IIS logs? If you're not checking the
I am refering to the IIS logs.
IIS logs, check them to see if the number of requests matches the number of
requests in the .NET WS logs.
I wasn't aware of those! Where are they located?

good luck,
Waleed
"ja*****@texeme.com" wrote:

PS -- I also have tracing and logging on the web service -- those calls
are never recorded there.
Waleed Abdulla xrules org> <waleed_abdulla wrote:
It could be that error messages are generated, but not received. This is the
case with one-way Web services where the Web service is defined to NOT return
any value. In that case, the proxy sends the SOAP message and closes the
connection right away without waiting to see if SOAP Faults are returned. Try
to force your Web service to return some value (or change the proxy generated
file) and try again. You might start receiving a lot of errors.

Waleed
"ja*****@texeme.com" wrote:

I wrote a program that loops through a file of records.

It parses each line in the file and sends them to a web service that
inserts them into an AS400DB2 database using Asynch calls.

This is the wierd part. Say their are 500 records in the file.

If I run the process once, maybe 250 will appear.

If I run it a second time, maybe 400 or all the records will appear.

Usually the third time I run it, all 500 appear.

From the consuming program, that reads the records, there is never any
error message thrown. There are always 500 calls to the web service.

I can see from my web server logs that the service is just not called
when the records are not written, so I don't think its on the database side.

So my question is: If they don't error out, where do all these web
services calls go?? I ASP.NET webservices just that flawed and
inconsistent that it cannot be depended on for this type of operation?

Would a more robust web server such as Apache 2.0 help?


Nov 23 '05 #25

P: n/a
> > 2. Could it be that the the processing on the server is slow, and your web
server is overwhelmved? If the IIS pipe is full, I suspect it will reject new
requests without passing them to .NET to be logged and processed.


Quite possibly. I thought it was a dual proc, but now looking via the
MMC is is single proc!


This theory should be easy to test. Put a delay or something to slow down
your client and see if there is a difference.

Also, you mentioned that in the third attemp all goes fine. How long do you
need to leave a period of inactivity before the Web service starts acting up
again?

IIS logs, check them to see if the number of requests matches the number of
requests in the .NET WS logs.


I wasn't aware of those! Where are they located?


I'm refering to the tracing logs. These can be activated if you're using WSE
2.0. They keep a log of the complete message in a file for debugging.
However, if the request is not showing on your IIS logs then it's not going
to show on your .NET trace anyway.
Nov 23 '05 #26

P: n/a
> > 2. Could it be that the the processing on the server is slow, and your web
server is overwhelmved? If the IIS pipe is full, I suspect it will reject new
requests without passing them to .NET to be logged and processed.


Quite possibly. I thought it was a dual proc, but now looking via the
MMC is is single proc!


This theory should be easy to test. Put a delay or something to slow down
your client and see if there is a difference.

Also, you mentioned that in the third attemp all goes fine. How long do you
need to leave a period of inactivity before the Web service starts acting up
again?

IIS logs, check them to see if the number of requests matches the number of
requests in the .NET WS logs.


I wasn't aware of those! Where are they located?


I'm refering to the tracing logs. These can be activated if you're using WSE
2.0. They keep a log of the complete message in a file for debugging.
However, if the request is not showing on your IIS logs then it's not going
to show on your .NET trace anyway.
Nov 23 '05 #27

P: n/a
Indeed, it is likely that you are running into the limit of 10 users on
Windows XP. But even if you upgraded to Windows 20003 Server which does not
have this limit, it is still possible to overflow the IIS request queue. You
can increase the request queue size through IIS configuration, but if you
push many requests you can eventually overflow the queue no matter how large
you make it.

The real solution IMO is to handle the error in the client, wait for a while
and then retry the requests that failed.

Regards.
Sami

"John Bailo" <ja*****@texeme.com> wrote in message
news:rP********************@speakeasy.net...

More info. See article below.

So, what I think is:

My dev workstation is an XP Pro machine. I'm assuming that it has the 10
user limit ( which is great from a marketing perspective that M$ can limit
people from running an XP server, but sucks eggs as far as me, the
developer, wanting to benchtest a production web service locally!) The
article says that even if I disable the keep-lives, I still am up against
the 10 person limit....in fact, by disabling the keep alives, my web
service calls probably happen so fast they overwhelm the II5 server on XP
and thus the lock up decribed below ( possibly ).

So, my guess is the disabling of the Keep-Alives on my production web
server ( which is running 2k server ) may have the intended effect of
lessening the number of calls to the web service that return the 403.9
error.

We'll see!

http://support.microsoft.com/default...b;en-us;262635

Error Message: HTTP 403.9 - Access Forbidden: Too many users are connected

RESOLUTION
If more than ten connections are needed, use the version of IIS 5.0 that
is included in Windows 2000 Server.

If you use IIS 5.0 on Windows 2000 Professional or IIS 5.1 on Microsoft
Windows XP Professional, disable HTTP keep-alives in the properties of the
Web site. When you do this, a limit of 10 concurrent connections still
exists, but IIS does not maintain connections for inactive users.

John Bailo wrote:

Well, maybe not.

I set the keep alives off and when I ran the program, it loaded 20
records and then locked up in studio without ever getting to a breakpoint
or error.

John Bailo wrote:

This might be an answer:

http://www.dotnet247.com/247referenc...43/219122.aspx

"I eventually found a couple KB article explaining this and the solution
(262635 - Error Message: HTTP 403.9 - Access Forbidden: Too Many Users
Are
Connected, 308186 - HOW TO: Optimize Web Server Performance in Windows
2000). The keep-alives can be disabled through IIS admin interface. This
resolves my problem."

John Bailo wrote:
Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a file,
in quick succession. For 29 of those calls, the method threw this
error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29 times
out of 380 when called asynchronously?

Sami Vaaraniemi wrote:

> There is a client-side limit to how many simultaneous calls you can
> make from one AppDomain to one web service (see the
> ServicePointManager.DefaultCon*nectionLimit property). Make sure that
> the calls are not dropped in the client side. You should see an
> exception in the callback of the async call if the call is not
> completed.
>
> Also, you could try debugging the problem by using your own threads to
> issue the calls instead of using the built-in BeginXXX methods. This
> way you could log every outgoing call and determine if and where the
> calls are dropped.
>
> Regards,
> Sami
>
> <ja*****@texeme.com> wrote in message
> news:sJ********************@speakeasy.net...
>
>> I would buy that explaination, except the web service server logs (
>> iis ) don't show those missing calls.
>>
>> So, where are those calls?
>>
>> Waleed Abdulla xrules org> <waleed_abdulla wrote:
>>
>>> It could be that error messages are generated, but not received.
>>> This is the case with one-way Web services where the Web service is
>>> defined to NOT return any value. In that case, the proxy sends the
>>> SOAP message and closes the connection right away without waiting to
>>> see if SOAP Faults are returned. Try to force your Web service to
>>> return some value (or change the proxy generated file) and try
>>> again. You might start receiving a lot of errors.
>>>
>>> Waleed
>>>
>>>
>>> "ja*****@texeme.com" wrote:
>>>
>>>
>>>
>>>> I wrote a program that loops through a file of records.
>>>>
>>>> It parses each line in the file and sends them to a web service
>>>> that inserts them into an AS400DB2 database using Asynch calls.
>>>>
>>>> This is the wierd part. Say their are 500 records in the file.
>>>>
>>>> If I run the process once, maybe 250 will appear.
>>>>
>>>> If I run it a second time, maybe 400 or all the records will
>>>> appear.
>>>>
>>>> Usually the third time I run it, all 500 appear.
>>>>
>>>> From the consuming program, that reads the records, there is never
>>>> any error message thrown. There are always 500 calls to the web
>>>> service.
>>>>
>>>> I can see from my web server logs that the service is just not
>>>> called when the records are not written, so I don't think its on
>>>> the database side.
>>>>
>>>> So my question is: If they don't error out, where do all these web
>>>> services calls go?? I ASP.NET webservices just that flawed and
>>>> inconsistent that it cannot be depended on for this type of
>>>> operation?
>>>>
>>>> Would a more robust web server such as Apache 2.0 help?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
>

Nov 23 '05 #28

P: n/a
Indeed, it is likely that you are running into the limit of 10 users on
Windows XP. But even if you upgraded to Windows 20003 Server which does not
have this limit, it is still possible to overflow the IIS request queue. You
can increase the request queue size through IIS configuration, but if you
push many requests you can eventually overflow the queue no matter how large
you make it.

The real solution IMO is to handle the error in the client, wait for a while
and then retry the requests that failed.

Regards.
Sami

"John Bailo" <ja*****@texeme.com> wrote in message
news:rP********************@speakeasy.net...

More info. See article below.

So, what I think is:

My dev workstation is an XP Pro machine. I'm assuming that it has the 10
user limit ( which is great from a marketing perspective that M$ can limit
people from running an XP server, but sucks eggs as far as me, the
developer, wanting to benchtest a production web service locally!) The
article says that even if I disable the keep-lives, I still am up against
the 10 person limit....in fact, by disabling the keep alives, my web
service calls probably happen so fast they overwhelm the II5 server on XP
and thus the lock up decribed below ( possibly ).

So, my guess is the disabling of the Keep-Alives on my production web
server ( which is running 2k server ) may have the intended effect of
lessening the number of calls to the web service that return the 403.9
error.

We'll see!

http://support.microsoft.com/default...b;en-us;262635

Error Message: HTTP 403.9 - Access Forbidden: Too many users are connected

RESOLUTION
If more than ten connections are needed, use the version of IIS 5.0 that
is included in Windows 2000 Server.

If you use IIS 5.0 on Windows 2000 Professional or IIS 5.1 on Microsoft
Windows XP Professional, disable HTTP keep-alives in the properties of the
Web site. When you do this, a limit of 10 concurrent connections still
exists, but IIS does not maintain connections for inactive users.

John Bailo wrote:

Well, maybe not.

I set the keep alives off and when I ran the program, it loaded 20
records and then locked up in studio without ever getting to a breakpoint
or error.

John Bailo wrote:

This might be an answer:

http://www.dotnet247.com/247referenc...43/219122.aspx

"I eventually found a couple KB article explaining this and the solution
(262635 - Error Message: HTTP 403.9 - Access Forbidden: Too Many Users
Are
Connected, 308186 - HOW TO: Optimize Web Server Performance in Windows
2000). The keep-alives can be disabled through IIS admin interface. This
resolves my problem."

John Bailo wrote:
Ok, we're getting closer.

Using Sami's advice, I nested the End_ method in a try/catch block.

I immediately saw an error, but I'm not sure what to do about it.

So, I called the web service 380 times, once for each record in a file,
in quick succession. For 29 of those calls, the method threw this
error:

"The request failed with HTTP status 403: Access Forbidden."

Can anyone suggest why the web service would throw this error 29 times
out of 380 when called asynchronously?

Sami Vaaraniemi wrote:

> There is a client-side limit to how many simultaneous calls you can
> make from one AppDomain to one web service (see the
> ServicePointManager.DefaultCon*nectionLimit property). Make sure that
> the calls are not dropped in the client side. You should see an
> exception in the callback of the async call if the call is not
> completed.
>
> Also, you could try debugging the problem by using your own threads to
> issue the calls instead of using the built-in BeginXXX methods. This
> way you could log every outgoing call and determine if and where the
> calls are dropped.
>
> Regards,
> Sami
>
> <ja*****@texeme.com> wrote in message
> news:sJ********************@speakeasy.net...
>
>> I would buy that explaination, except the web service server logs (
>> iis ) don't show those missing calls.
>>
>> So, where are those calls?
>>
>> Waleed Abdulla xrules org> <waleed_abdulla wrote:
>>
>>> It could be that error messages are generated, but not received.
>>> This is the case with one-way Web services where the Web service is
>>> defined to NOT return any value. In that case, the proxy sends the
>>> SOAP message and closes the connection right away without waiting to
>>> see if SOAP Faults are returned. Try to force your Web service to
>>> return some value (or change the proxy generated file) and try
>>> again. You might start receiving a lot of errors.
>>>
>>> Waleed
>>>
>>>
>>> "ja*****@texeme.com" wrote:
>>>
>>>
>>>
>>>> I wrote a program that loops through a file of records.
>>>>
>>>> It parses each line in the file and sends them to a web service
>>>> that inserts them into an AS400DB2 database using Asynch calls.
>>>>
>>>> This is the wierd part. Say their are 500 records in the file.
>>>>
>>>> If I run the process once, maybe 250 will appear.
>>>>
>>>> If I run it a second time, maybe 400 or all the records will
>>>> appear.
>>>>
>>>> Usually the third time I run it, all 500 appear.
>>>>
>>>> From the consuming program, that reads the records, there is never
>>>> any error message thrown. There are always 500 calls to the web
>>>> service.
>>>>
>>>> I can see from my web server logs that the service is just not
>>>> called when the records are not written, so I don't think its on
>>>> the database side.
>>>>
>>>> So my question is: If they don't error out, where do all these web
>>>> services calls go?? I ASP.NET webservices just that flawed and
>>>> inconsistent that it cannot be depended on for this type of
>>>> operation?
>>>>
>>>> Would a more robust web server such as Apache 2.0 help?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
>

Nov 23 '05 #29

P: n/a
Sami Vaaraniemi wrote:
The real solution IMO is to handle the error in the client, wait for a
while and then retry the requests that failed.


I absolutely agree...that programmatic solution will work no matter which
class of web server that it's consuming the web service from.

--
Texeme Textcasting Technology
http://www.texeme.com
Nov 23 '05 #30

P: n/a
Sami Vaaraniemi wrote:
The real solution IMO is to handle the error in the client, wait for a
while and then retry the requests that failed.


I absolutely agree...that programmatic solution will work no matter which
class of web server that it's consuming the web service from.

--
Texeme Textcasting Technology
http://www.texeme.com
Nov 23 '05 #31

This discussion thread is closed

Replies have been disabled for this discussion.