«

I am developing a WCF Comet web service, where client requests gets queued
until a response is available. The connection to the client is thus open a
long time, and in the Comet pattern timeouts is a factor that needs to be
addressed. It can for instance be a proxy server between the client and
server that has a short timeout that disconnects before the server or
client.

Now, the question is how to get a handle to the response so that I can check
if the client is still connected?

Regards;
/jb

Hi Jonny,

As for the WCF Comet service scenario you mentioned, I think what you need
now is some means to check the client connection status when the
server-side finished the method(and ready to return).

So far based on my research, at server-side, WCF method can use
"OperationContext.Current" to inspect some WCF method invocation context
info. And the OperationContext class has a "InstanceContext" property that
can help inspect the current communication object's State:

#OperationContext Class
http://msdn.microsoft.com/en-us/libr...erationcontext
.aspx

For example:

========================
public string GetStringData()
{

OperationContext.Current.InstanceContext.State
}
========================

BTW, since your server-side WCF operation will take long time to process,
have you used async method call pattern at client-side? I think using async
approach will make the client-side UI responding perform better.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subs.../aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>From: "Jonny Bergdahl" <>
>Subject: Comet implementation in WCF
>Date: Wed, 19 Nov 2008 11:02:52 +0100

>
>I am developing a WCF Comet web service, where client requests gets queued
>until a response is available. The connection to the client is thus open a
>long time, and in the Comet pattern timeouts is a factor that needs to be
>addressed. It can for instance be a proxy server between the client and
>server that has a short timeout that disconnects before the server or
>client.
>
>Now, the question is how to get a handle to the response so that I can
check
>if the client is still connected?
>
>Regards;
>/jb
>
>

> now is some means to check the client connection status when the
> server-side finished the method(and ready to return).

Yes.

> info. And the OperationContext class has a "InstanceContext" property that
> can help inspect the current communication object's State:

Seems to be exactly what I am looking for. I also notice that it has a
Closing event that I can hook up to forward the disconnect directly to my
service queue. That would mean that I have to store the InstanceContext
along the request in my queue object. Is that valid?

> BTW, since your server-side WCF operation will take long time to process,
> have you used async method call pattern at client-side? I think using
> async
> approach will make the client-side UI responding perform better.

I have used the async pattern on the server, all requests are moved to a
separate thread that keeps a queue of the waiting clients. That way I won't
exhaust the thread pool used to receive the requests, as we are designing
for 500+ clients.

The client on the other hand is a Windows service whose sole purpose is to
wait for the service response, so there might not be a need to use the async
pattern (depending on how I can process a service stop request).

Regards;
/jb

Thanks for your reply Jonny,

The "OperationContext" and "InstanceContext" should be available at least
during the entire WCF method processing lifecycle. Also, generally if the
code is within the same callstack/thread as the WCF's operation method, it
can access the Instancecontext via OperationContext. If you switch to other
threads(which is not synchronized with the main WCF operation method
calling thread), it is not guranteed that you can access the
operationContext.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
.



--------------------
>From: "Jonny Bergdahl" <>
>References: <#>
<>
>In-Reply-To: <>
>Subject: Re: Comet implementation in WCF
>Date: Thu, 20 Nov 2008 09:47:43 +0100

>
>> now is some means to check the client connection status when the
>> server-side finished the method(and ready to return).
>
>Yes.
>
>> info. And the OperationContext class has a "InstanceContext" property
that
>> can help inspect the current communication object's State:
>
>Seems to be exactly what I am looking for. I also notice that it has a
>Closing event that I can hook up to forward the disconnect directly to my
>service queue. That would mean that I have to store the InstanceContext
>along the request in my queue object. Is that valid?
>
>> BTW, since your server-side WCF operation will take long time to process,
>> have you used async method call pattern at client-side? I think using
>> async
>> approach will make the client-side UI responding perform better.
>
>I have used the async pattern on the server, all requests are moved to a
>separate thread that keeps a queue of the waiting clients. That way I
won't
>exhaust the thread pool used to receive the requests, as we are designing
>for 500+ clients.
>
>The client on the other hand is a Windows service whose sole purpose is to
>wait for the service response, so there might not be a need to use the
async
>pattern (depending on how I can process a service stop request).
>
>Regards;
>/jb
>
>

If I understand You correct, this means I need to capture the instance of
the InstanceContext inside of the BeginXxxx() (where it is available using
and forward that instance to my queue. This would eliminate the need to use
the OperationContext method inside my Queue thread (which is a manually
created thread running outside of the thread pool).

Regards;
/jb


""Steven Cheng"" <> skrev i meddelandet
news:...
> Thanks for your reply Jonny,
>
> The "OperationContext" and "InstanceContext" should be available at least
> during the entire WCF method processing lifecycle. Also, generally if the
> code is within the same callstack/thread as the WCF's operation method, it
> can access the Instancecontext via OperationContext. If you switch to
> other
> threads(which is not synchronized with the main WCF operation method
> calling thread), it is not guranteed that you can access the
> operationContext.
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead
>
>
> Delighting our customers is our #1 priority. We welcome your comments and
> suggestions about how we can improve the support we provide to you. Please
> feel free to let my manager know what you think of the level of service
> provided. You can send feedback directly to my manager at:
> .
>
>
>
> --------------------
>>From: "Jonny Bergdahl" <>
>>References: <#>
> <>
>>In-Reply-To: <>
>>Subject: Re: Comet implementation in WCF
>>Date: Thu, 20 Nov 2008 09:47:43 +0100
>
>>
>>> now is some means to check the client connection status when the
>>> server-side finished the method(and ready to return).
>>
>>Yes.
>>
>>> info. And the OperationContext class has a "InstanceContext" property
> that
>>> can help inspect the current communication object's State:
>>
>>Seems to be exactly what I am looking for. I also notice that it has a
>>Closing event that I can hook up to forward the disconnect directly to my
>>service queue. That would mean that I have to store the InstanceContext
>>along the request in my queue object. Is that valid?
>>
>>> BTW, since your server-side WCF operation will take long time to
>>> process,
>>> have you used async method call pattern at client-side? I think using
>>> async
>>> approach will make the client-side UI responding perform better.
>>
>>I have used the async pattern on the server, all requests are moved to a
>>separate thread that keeps a queue of the waiting clients. That way I
> won't
>>exhaust the thread pool used to receive the requests, as we are designing
>>for 500+ clients.
>>
>>The client on the other hand is a Windows service whose sole purpose is to
>>wait for the service response, so there might not be a need to use the
> async
>>pattern (depending on how I can process a service stop request).
>>
>>Regards;
>>/jb
>>
>>
>

Thanks for your reply Jonny,

Yes, since you're using beginXXX to perform async operation, it will result
to a new background thread-pool thread which may not contain the context
info as the original one. You'd better use some own variables(accessible in
the new async thread context) to cache the OperationContext or
Instancecontext if you want. Also, I think it's better to perform some
tests to verify that that does work as you expect.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
.


--------------------
>From: "Jonny Bergdahl" <>
>Subject: Re: Comet implementation in WCF
>Date: Fri, 21 Nov 2008 09:58:16 +0100

>
>If I understand You correct, this means I need to capture the instance of
>the InstanceContext inside of the BeginXxxx() (where it is available using
>and forward that instance to my queue. This would eliminate the need to
use
>the OperationContext method inside my Queue thread (which is a manually
>created thread running outside of the thread pool).
>
>Regards;
>/jb
>
>
>""Steven Cheng"" <> skrev i meddelandet
>news:...
>> Thanks for your reply Jonny,
>>
>> The "OperationContext" and "InstanceContext" should be available at least
>> during the entire WCF method processing lifecycle. Also, generally if the
>> code is within the same callstack/thread as the WCF's operation method,
it
>> can access the Instancecontext via OperationContext. If you switch to
>> other
>> threads(which is not synchronized with the main WCF operation method
>> calling thread), it is not guranteed that you can access the
>> operationContext.
>>
>> Sincerely,
>>
>> Steven Cheng
>>
>> Microsoft MSDN Online Support Lead
>>
>>
>> Delighting our customers is our #1 priority. We welcome your comments and
>> suggestions about how we can improve the support we provide to you.
Please
>> feel free to let my manager know what you think of the level of service
>> provided. You can send feedback directly to my manager at:
>> .
>>
>>
>>
>> --------------------
>>>From: "Jonny Bergdahl" <>
>>>References: <#>
>> <>
>>>In-Reply-To: <>
>>>Subject: Re: Comet implementation in WCF
>>>Date: Thu, 20 Nov 2008 09:47:43 +0100
>>
>>>
>>>> now is some means to check the client connection status when the
>>>> server-side finished the method(and ready to return).
>>>
>>>Yes.
>>>
>>>> info. And the OperationContext class has a "InstanceContext" property
>> that
>>>> can help inspect the current communication object's State:
>>>
>>>Seems to be exactly what I am looking for. I also notice that it has a
>>>Closing event that I can hook up to forward the disconnect directly to my
>>>service queue. That would mean that I have to store the InstanceContext
>>>along the request in my queue object. Is that valid?
>>>
>>>> BTW, since your server-side WCF operation will take long time to
>>>> process,
>>>> have you used async method call pattern at client-side? I think using
>>>> async
>>>> approach will make the client-side UI responding perform better.
>>>
>>>I have used the async pattern on the server, all requests are moved to a
>>>separate thread that keeps a queue of the waiting clients. That way I
>> won't
>>>exhaust the thread pool used to receive the requests, as we are designing
>>>for 500+ clients.
>>>
>>>The client on the other hand is a Windows service whose sole purpose is
to
>>>wait for the service response, so there might not be a need to use the
>> async
>>>pattern (depending on how I can process a service stop request).
>>>
>>>Regards;
>>>/jb
>>>
>>>
>>
>
>

Thanks! Will try this.

Regards;
/jb

""Steven Cheng"" <> skrev i meddelandet
news:...
> Thanks for your reply Jonny,
>
> Yes, since you're using beginXXX to perform async operation, it will
> result
> to a new background thread-pool thread which may not contain the context
> info as the original one. You'd better use some own variables(accessible
> in
> the new async thread context) to cache the OperationContext or
> Instancecontext if you want. Also, I think it's better to perform some
> tests to verify that that does work as you expect.
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead
>
>
> Delighting our customers is our #1 priority. We welcome your comments and
> suggestions about how we can improve the support we provide to you. Please
> feel free to let my manager know what you think of the level of service
> provided. You can send feedback directly to my manager at:
> .
>
>
> --------------------
>>From: "Jonny Bergdahl" <>
>>Subject: Re: Comet implementation in WCF
>>Date: Fri, 21 Nov 2008 09:58:16 +0100
>
>>
>>If I understand You correct, this means I need to capture the instance of
>>the InstanceContext inside of the BeginXxxx() (where it is available using
>>and forward that instance to my queue. This would eliminate the need to
> use
>>the OperationContext method inside my Queue thread (which is a manually
>>created thread running outside of the thread pool).
>>
>>Regards;
>>/jb
>>
>>
>>""Steven Cheng"" <> skrev i meddelandet
>>news:.. .
>>> Thanks for your reply Jonny,
>>>
>>> The "OperationContext" and "InstanceContext" should be available at
>>> least
>>> during the entire WCF method processing lifecycle. Also, generally if
>>> the
>>> code is within the same callstack/thread as the WCF's operation method,
> it
>>> can access the Instancecontext via OperationContext. If you switch to
>>> other
>>> threads(which is not synchronized with the main WCF operation method
>>> calling thread), it is not guranteed that you can access the
>>> operationContext.
>>>
>>> Sincerely,
>>>
>>> Steven Cheng
>>>
>>> Microsoft MSDN Online Support Lead
>>>
>>>
>>> Delighting our customers is our #1 priority. We welcome your comments
>>> and
>>> suggestions about how we can improve the support we provide to you.
> Please
>>> feel free to let my manager know what you think of the level of service
>>> provided. You can send feedback directly to my manager at:
>>> .
>>>
>>>
>>>
>>> --------------------
>>>>From: "Jonny Bergdahl" <>
>>>>References: <#>
>>> <>
>>>>In-Reply-To: <>
>>>>Subject: Re: Comet implementation in WCF
>>>>Date: Thu, 20 Nov 2008 09:47:43 +0100
>>>
>>>>
>>>>> now is some means to check the client connection status when the
>>>>> server-side finished the method(and ready to return).
>>>>
>>>>Yes.
>>>>
>>>>> info. And the OperationContext class has a "InstanceContext" property
>>> that
>>>>> can help inspect the current communication object's State:
>>>>
>>>>Seems to be exactly what I am looking for. I also notice that it has a
>>>>Closing event that I can hook up to forward the disconnect directly to
>>>>my
>>>>service queue. That would mean that I have to store the InstanceContext
>>>>along the request in my queue object. Is that valid?
>>>>
>>>>> BTW, since your server-side WCF operation will take long time to
>>>>> process,
>>>>> have you used async method call pattern at client-side? I think using
>>>>> async
>>>>> approach will make the client-side UI responding perform better.
>>>>
>>>>I have used the async pattern on the server, all requests are moved to a
>>>>separate thread that keeps a queue of the waiting clients. That way I
>>> won't
>>>>exhaust the thread pool used to receive the requests, as we are
>>>>designing
>>>>for 500+ clients.
>>>>
>>>>The client on the other hand is a Windows service whose sole purpose is
> to
>>>>wait for the service response, so there might not be a need to use the
>>> async
>>>>pattern (depending on how I can process a service stop request).
>>>>
>>>>Regards;
>>>>/jb
>>>>
>>>>
>>>
>>
>>
>

> So far based on my research, at server-side, WCF method can use
> "OperationContext.Current" to inspect some WCF method invocation context
> info. And the OperationContext class has a "InstanceContext" property that
> can help inspect the current communication object's State:

Sorry for the late reply, I haven't come around to this until now.

I am sorry to report that this does not work. The
OperationContext.Current.InstanceContext.State only seems to track the
internal state of thre service object, and not the communication state.

When I have initiated a connection from the client, State is set top Opened.
But even after I have closed down the Client, it is still set to Opened even
though the HTTP connection is closed.

What I need is to keep track of the underlying HTTP connection state,
something like HttpResponse.IsClientConnected.

Any other ideas on how to get to the underlying connection?

Regards;
/jb

Hi Jonny,

I've seen your new thread and posted my reply there. Here is my reply
content for your convenience:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hi Jonny,

Thanks for your followup.

Also sorry for the late reponse as I was dealing with some other issues
recently. Regarding on the detecting client-side disconnecting problem,
I've also performed some further research. It seems for normal one-way
binding(comparing to thte duplex binding), the client-side disconnect
detection is not real-time. Here are some web articles discussing on this
issue:

#WCF Notification on Disconnect
http://www.rcs-solutions.com/blog/20...Disconnect.asp
x

#Taking Action on Client Close
http://blogs.msdn.com/drnick/archive...on-client-clos
e.aspx

#Provide Way to Detect Client Abort/Disconnect in WCF
http://social.msdn.microsoft.com/For...e30-fc74-4a52-
9dfd-232c67c84f7a

I've tried registering some eventhandler on the OperationContext's Channel,
but those event won't be raised until the service method return data to
client-side. e.g,

========================
public string GetData(string user)
{
Console.WriteLine("GetData Begin:{0}", DateTime.Now);


OperationContext oc = OperationContext.Current;


oc.Channel.Closed += new EventHandler(Channel_Closed);
oc.Channel.Closing += new EventHandler(Channel_Closing);
oc.Channel.Faulted += new EventHandler(Channel_Faulted);


for (int i = 0; i < 10; ++i)
{
Console.WriteLine("Loop:{0}, State:{1}",i,
oc.Channel.State);


Thread.Sleep(1000 * 3);
}


Console.WriteLine("GetData End:{0}", DateTime.Now);

return "result of " + user;

}
===============================

If duplex binding is possible for your scenario, you may have a try on the
solution mentioned in above articles.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.


--------------------
>From: "Jonny Bergdahl" <>
>Subject: Re: Comet implementation in WCF
>Date: Thu, 15 Jan 2009 10:55:42 +0100

>> So far based on my research, at server-side, WCF method can use
>> "OperationContext.Current" to inspect some WCF method invocation context
>> info. And the OperationContext class has a "InstanceContext" property
that
>> can help inspect the current communication object's State:
>
>Sorry for the late reply, I haven't come around to this until now.
>
>I am sorry to report that this does not work. The
>OperationContext.Current.InstanceContext.State only seems to track the
>internal state of thre service object, and not the communication state.
>
>When I have initiated a connection from the client, State is set top
Opened.
>But even after I have closed down the Client, it is still set to Opened
even
>though the HTTP connection is closed.
>
>What I need is to keep track of the underlying HTTP connection state,
>something like HttpResponse.IsClientConnected.
>
>Any other ideas on how to get to the underlying connection?
>
>Regards;
>/jb
>
>