Timeout for method in service

I have a service (InstanceContextMode.Single) that has a couple of methods
accessible through a basicHttpBinding in WCF.

One of these methods is a "receive"-methods" which checks for new messages.
The method loops until a new message is ready, and then returns this message.

A TimeoutException is thrown when the client has waited for more than 1
minute (default value) for the receive-method to return. Each time that the
exception has been caught, the client calls the same method again.

The problem is that the method in the service keeps running, and will return
when a new message arrives, but the client never receives it.

So, is it possible to stop the execution of the method in the service if the
client has timed out, i.e. have them both time out after the same period of
time?

The simple answer to your question is "yes," but without knowing more about
what your application does my first question would be "is this the best
architecture?"

Is your client waiting to receive messages from your service, that are sent
to the service from some other process or method?

For example, your client is waiting to be notified that MSFT stock has hit a
specified value, and when that occurs your service will send the message to
the client.

Dumb example, but if this the general idea then you might want to consider a
publish & subscribe design, or possibly one-way calls instead.

Tell me more ..........
--
Stay Mobile


"ottogbg" wrote:

> I have a service (InstanceContextMode.Single) that has a couple of methods
> accessible through a basicHttpBinding in WCF.
>
> One of these methods is a "receive"-methods" which checks for new messages.
> The method loops until a new message is ready, and then returns this message.
>
> A TimeoutException is thrown when the client has waited for more than 1
> minute (default value) for the receive-method to return. Each time that the
> exception has been caught, the client calls the same method again.
>
> The problem is that the method in the service keeps running, and will return
> when a new message arrives, but the client never receives it.
>
> So, is it possible to stop the execution of the method in the service if the
> client has timed out, i.e. have them both time out after the same period of
> time?

It will be a better solution to make a contrack with a callback.

"ottogbg" <ottogbg@discussions.microsoft.com> wrote in message
news:7D543D0B-118F-4859-925D-BB61C3A80B64@microsoft.com...
>I have a service (InstanceContextMode.Single) that has a couple of methods
> accessible through a basicHttpBinding in WCF.
>
> One of these methods is a "receive"-methods" which checks for new
> messages.
> The method loops until a new message is ready, and then returns this
> message.
>
> A TimeoutException is thrown when the client has waited for more than 1
> minute (default value) for the receive-method to return. Each time that
> the
> exception has been caught, the client calls the same method again.
>
> The problem is that the method in the service keeps running, and will
> return
> when a new message arrives, but the client never receives it.
>
> So, is it possible to stop the execution of the method in the service if
> the
> client has timed out, i.e. have them both time out after the same period
> of
> time?

Add another method Stop() which you call on the service before client gone
so it will case your service stop to check messages and Start() for v.v
operation
Arkady

"ottogbg" <ottogbg@discussions.microsoft.com> wrote in message
news:7D543D0B-118F-4859-925D-BB61C3A80B64@microsoft.com...
>I have a service (InstanceContextMode.Single) that has a couple of methods
> accessible through a basicHttpBinding in WCF.
>
> One of these methods is a "receive"-methods" which checks for new
> messages.
> The method loops until a new message is ready, and then returns this
> message.
>
> A TimeoutException is thrown when the client has waited for more than 1
> minute (default value) for the receive-method to return. Each time that
> the
> exception has been caught, the client calls the same method again.
>
> The problem is that the method in the service keeps running, and will
> return
> when a new message arrives, but the client never receives it.
>
> So, is it possible to stop the execution of the method in the service if
> the
> client has timed out, i.e. have them both time out after the same period
> of
> time?

"MobileMan" wrote:
> The simple answer to your question is "yes," but without knowing more about
> what your application does my first question would be "is this the best
> architecture?"
>
> Is your client waiting to receive messages from your service, that are sent
> to the service from some other process or method?
>
> For example, your client is waiting to be notified that MSFT stock has hit a
> specified value, and when that occurs your service will send the message to
> the client.
>
> Dumb example, but if this the general idea then you might want to consider a
> publish & subscribe design, or possibly one-way calls instead.
>
> Tell me more ..........

True, that is basically the concept. See below.

"Mariano Omar Rodriguez" wrote:
> It will be a better solution to make a contrack with a callback.

I have considered callbacks, and it does the work really well, the problem
is compability with WS-clients. I have not been able to consume a
wsDualHttpBinding in a Java client. That is why I have this design.

"Arkady Frenkel" wrote:
> Add another method Stop() which you call on the service before client gone
> so it will case your service stop to check messages and Start() for v.v
> operation
> Arkady

That can work, although the callback approach would work.

Thanks!

Then, I believe that you could use another WebMethod that making poolling
reports the status of the complition of the task.


"ottogbg" <ottogbg@discussions.microsoft.com> wrote in message
news:8BD8C6EF-C8FB-4B86-A5D5-34D3426BE61E@microsoft.com...
> "MobileMan" wrote:
>> The simple answer to your question is "yes," but without knowing more
>> about
>> what your application does my first question would be "is this the best
>> architecture?"
>>
>> Is your client waiting to receive messages from your service, that are
>> sent
>> to the service from some other process or method?
>>
>> For example, your client is waiting to be notified that MSFT stock has
>> hit a
>> specified value, and when that occurs your service will send the message
>> to
>> the client.
>>
>> Dumb example, but if this the general idea then you might want to
>> consider a
>> publish & subscribe design, or possibly one-way calls instead.
>>
>> Tell me more ..........
>
> True, that is basically the concept. See below.
>
> "Mariano Omar Rodriguez" wrote:
>> It will be a better solution to make a contrack with a callback.
>
> I have considered callbacks, and it does the work really well, the problem
> is compability with WS-clients. I have not been able to consume a
> wsDualHttpBinding in a Java client. That is why I have this design.
>
> "Arkady Frenkel" wrote:
>> Add another method Stop() which you call on the service before client
>> gone
>> so it will case your service stop to check messages and Start() for v.v
>> operation
>> Arkady
>
> That can work, although the callback approach would work.
>
> Thanks!