"Odd Jarle Ostvik" <odd.ostvik.nospam@agr.nospam> wrote in message
news:84468D0E-FCCA-4CAF-92BB-90D5785C8093@microsoft.com...
> Hi,
> I enabled WSE tracing, sent one request from the client and got the SOAP
> env. in InputTrace.webinfo, but nothing in OutputTrace. I then sent
another
> request, and after approx. 1 minute, I got a Timeout SOAP fault in the
output
> trace.
>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>System.Web.Services.Protocols.SoapHeaderException: Server
> unavailable, please try later ---> System.ServiceProcess.TimeoutException:
> WSE832: The thread exceeded the executionTimeout limit while processing a
> message.
> --- End of inner exception stack trace ---</faultstring>
>

> </soap:Fault>
>
> After some more testing I found that I get n messages in InputTrace, and
n-1
> messages in Output trace. The first message in the queue, doesn't get any
> response, and is lost.
>
> I restartet the service, sent one new request, attached to the running
> process and then choosed break-all. It seemed that the WSE thread was
locked
> at location
> 'System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated' with
> 'Microsoft.Web.Services2.Xml.XmlSerializerCache.GetXmlSerializer'
somewhere
> down the stacktrace.
>
> I then sent some more requests, and all of their threads was locked up at
> location
'Microsoft.Web.Services2.Xml.XmlSerializerCache.GetXmlSerializer'.
>
> I will then conclude that it is the messages stuck at 'GetXmlSerializer'
> which generates faults, and that the first
> 'ExecWaitWithCaptureUnimpersonated' message just disappears.
>
> Is it policy/security settings? I've tried to run the service as
LocalSystem
> and with my own logon credentials.
>
> Thanks in advance,
> OJ
>
>
>
>
> "Dilip Krishnan" wrote:
>
> > Hello Odd,
> > Try turning WSE trace on just to see if the message actually is
consumed
> > by the soap service.
> >
> > HTH
> > Regards,
> > Dilip Krishnan
> > MCAD, MCSD.net
> > dkrishnan at geniant dot com
> > http://www.geniant.com
> >
> > > I have a SOAP Server (C#) implemented as a console application. This
> > > application is then hosted by a Windows Service (C++). The service
> > > starts the different applications including my SOAP server using
> > > function CreateProcess (Platform SDK).
> > >
> > > I ensure that the service and my server is running, and starts my
> > > Packet Sniffer. The server receives the packets, but doesn't respond
> > > to any requests. My test client receives a WSE101 exception when ths
> > > service is stopped.
> > >
> > > When I stop the service, and starts the SOAP Server in it's own
> > > context (Command Prompt) it works as it should.
> > >
> > > I have recreated the problem using QuickStart sample
> > > TcpSyncStockService.
> > >
> > > Has anyone experienced the same problem, or know about a solution,
> > > security setting etc. which solves the problem?
> > >
> > > Thanks,
> > > OJ
> >
> >
> >

"Sidd" wrote:

> Hi Odde,
>
> To eliminate your first error, you should look at the WSE.config file
> that is in the WSE installation directory which talks about
> executionTimeout.
> This is what is written,
>
> <messaging>
> <!--
>
> The allowRedirectedResponses element controls whether
> messages that contain
> From, ReplyTo or FaultTo value that redirect to a different
> endpoint are obeyed.
> The default is that they are not and that all response and
> fault messages are
> returned to the original sender. Enable this only if you
> require support for
> redirection of response and/or fault messages.
>
> <allowRedirectedResponses enabled="false" />
> -->
> <!--
>
> The executionTimeout section defines a user supplied maximum
> time in seconds that
> a request is allowed to process for. The default value is 90
> seconds.
> Specifying -1 means infinite.
>
> <executionTimeout value="90" />
>
> If you want to wait for a minute before sending the second message, you
> should also play around with the idleTimeout in. In particular, the
> WSE.config has the following 3 timeout values, but I think you would be most
> interested in the idle timeout value.
>
> <messaging>
> <transports>
> <add scheme="soap.tcp" >
> <idleTimeout value="120000" />
> <sendTimeout value="90000" />
> <receiveTimeout value="90000" />
> </add>
>
> Let me know if increasing these timeout values help your situation.
>
> Thanks,
>
> Sidd
>
>
> "Odd Jarle Ostvik" <odd.ostvik.nospam@agr.nospam> wrote in message
> news:84468D0E-FCCA-4CAF-92BB-90D5785C8093@microsoft.com...
> > Hi,
> > I enabled WSE tracing, sent one request from the client and got the SOAP
> > env. in InputTrace.webinfo, but nothing in OutputTrace. I then sent
> another
> > request, and after approx. 1 minute, I got a Timeout SOAP fault in the
> output
> > trace.
> >
> > <soap:Fault>
> > <faultcode>soap:Server</faultcode>
> > <faultstring>System.Web.Services.Protocols.SoapHeaderException: Server
> > unavailable, please try later ---> System.ServiceProcess.TimeoutException:
> > WSE832: The thread exceeded the executionTimeout limit while processing a
> > message.
> > --- End of inner exception stack trace ---</faultstring>
> >
> <faultactor>soap://stockservice.contoso.com/wse/samples/2003/06/TcpSyncStock
> Service</faultactor>
> > </soap:Fault>
> >
> > After some more testing I found that I get n messages in InputTrace, and
> n-1
> > messages in Output trace. The first message in the queue, doesn't get any
> > response, and is lost.
> >
> > I restartet the service, sent one new request, attached to the running
> > process and then choosed break-all. It seemed that the WSE thread was
> locked
> > at location
> > 'System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated' with
> > 'Microsoft.Web.Services2.Xml.XmlSerializerCache.GetXmlSerializer'
> somewhere
> > down the stacktrace.
> >
> > I then sent some more requests, and all of their threads was locked up at
> > location
> 'Microsoft.Web.Services2.Xml.XmlSerializerCache.GetXmlSerializer'.
> >
> > I will then conclude that it is the messages stuck at 'GetXmlSerializer'
> > which generates faults, and that the first
> > 'ExecWaitWithCaptureUnimpersonated' message just disappears.
> >
> > Is it policy/security settings? I've tried to run the service as
> LocalSystem
> > and with my own logon credentials.
> >
> > Thanks in advance,
> > OJ
> >
> >
> >
> >
> > "Dilip Krishnan" wrote:
> >
> > > Hello Odd,
> > > Try turning WSE trace on just to see if the message actually is
> consumed
> > > by the soap service.
> > >
> > > HTH
> > > Regards,
> > > Dilip Krishnan
> > > MCAD, MCSD.net
> > > dkrishnan at geniant dot com
> > > http://www.geniant.com
> > >
> > > > I have a SOAP Server (C#) implemented as a console application. This
> > > > application is then hosted by a Windows Service (C++). The service
> > > > starts the different applications including my SOAP server using
> > > > function CreateProcess (Platform SDK).
> > > >
> > > > I ensure that the service and my server is running, and starts my
> > > > Packet Sniffer. The server receives the packets, but doesn't respond
> > > > to any requests. My test client receives a WSE101 exception when ths
> > > > service is stopped.
> > > >
> > > > When I stop the service, and starts the SOAP Server in it's own
> > > > context (Command Prompt) it works as it should.
> > > >
> > > > I have recreated the problem using QuickStart sample
> > > > TcpSyncStockService.
> > > >
> > > > Has anyone experienced the same problem, or know about a solution,
> > > > security setting etc. which solves the problem?
> > > >
> > > > Thanks,
> > > > OJ
> > >
> > >
> > >
>
>