How do I cancel a lengthy process on server side?

[Ken Varn]

I have an ASP.NET form that may take a very long time to process a
particular request. If the user closes the browser window, the request will
continue to process until it completes. This is a problem when a user tries
to re-establish a new session. Since the previous request is still being
processed, the new request must now wait for it to complete. Is there
anyway to force old IIS processing thread sessions to terminate if they are
no longer active?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

[John Timney \(ASP.NET MVP\)]

You could take a look at the isClientConnect ed property to see if it helps.

http://msdn.microsoft.com/library/de...ectedTopic.asp

Its often useful to run this type of check in a serperate thread end
evaluate it alongside your executing long process, and work out a way to
cancel the process if the client becomes disconnected.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"Ken Varn" <nospam> wrote in message
news:Ot******** ******@TK2MSFTN GP12.phx.gbl...

I have an ASP.NET form that may take a very long time to process a
particular request. If the user closes the browser window, the request
will
continue to process until it completes. This is a problem when a user
tries
to re-establish a new session. Since the previous request is still being
processed, the new request must now wait for it to complete. Is there
anyway to force old IIS processing thread sessions to terminate if they
are
no longer active?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

[Ken Varn]

At the level where the processing is being performed, I do not have access
to the Page.Response object. This is being done in a generic C++ DLL that
is not ASP.NET aware. Is there any way that I can cancel an old processing
thread on the next new request that comes in or are there any other
solutions?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
"John Timney (ASP.NET MVP)" <ti*****@despam med.com> wrote in message
news:OG******** ******@TK2MSFTN GP14.phx.gbl...

You could take a look at the isClientConnect ed property to see if it helps.
http://msdn.microsoft.com/library/de...ectedTopic.asp
Its often useful to run this type of check in a serperate thread end
evaluate it alongside your executing long process, and work out a way to
cancel the process if the client becomes disconnected.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"Ken Varn" <nospam> wrote in message
news:Ot******** ******@TK2MSFTN GP12.phx.gbl...

I have an ASP.NET form that may take a very long time to process a
particular request. If the user closes the browser window, the request
will
continue to process until it completes. This is a problem when a user
tries
to re-establish a new session. Since the previous request is still being processed, the new request must now wait for it to complete. Is there
anyway to force old IIS processing thread sessions to terminate if they
are
no longer active?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

[William F. Robertson, Jr.]

Could you not just save a reference to the Thread object that is performing
the lengthly operation, and when you need to cancel the thread, could could
either signal the thread, but since you said it is interop, it might be best
to call Thread.Abort() on it.

Actually now that I think about it, I am not sure in the
ThreadAbortExce ption will be sent through interop code.

Hmmm....

bill
"Ken Varn" <nospam> wrote in message
news:eH******** ********@TK2MSF TNGP10.phx.gbl. ..

At the level where the processing is being performed, I do not have access
to the Page.Response object. This is being done in a generic C++ DLL that
is not ASP.NET aware. Is there any way that I can cancel an old processing thread on the next new request that comes in or are there any other
solutions?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
"John Timney (ASP.NET MVP)" <ti*****@despam med.com> wrote in message
news:OG******** ******@TK2MSFTN GP14.phx.gbl...

You could take a look at the isClientConnect ed property to see if it

helps.

http://msdn.microsoft.com/library/de...ectedTopic.asp

Its often useful to run this type of check in a serperate thread end
evaluate it alongside your executing long process, and work out a way to
cancel the process if the client becomes disconnected.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"Ken Varn" <nospam> wrote in message
news:Ot******** ******@TK2MSFTN GP12.phx.gbl...

I have an ASP.NET form that may take a very long time to process a
particular request. If the user closes the browser window, the request will
continue to process until it completes. This is a problem when a user
tries
to re-establish a new session. Since the previous request is still being processed, the new request must now wait for it to complete. Is there
anyway to force old IIS processing thread sessions to terminate if they are
no longer active?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

[Ken Varn]

The C++ module is managed, so maybe what you are saying will work.

So let me get this straight on what you are suggestion. Store the
Thread.CurrentT hread in a Session variable, then on re-entry call the Abort
method on the thread. I'll give that a shot. It sounds like it might work.
Are there any adverse ramifications to IIS if I do this? I wasn't sure if
there was some standard ASP.NET call that I should make to abort an IIS
thread.

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
"William F. Robertson, Jr." <th****@nameht. org> wrote in message
news:%2******** *******@TK2MSFT NGP10.phx.gbl.. .

Could you not just save a reference to the Thread object that is performing the lengthly operation, and when you need to cancel the thread, could could either signal the thread, but since you said it is interop, it might be best to call Thread.Abort() on it.

Actually now that I think about it, I am not sure in the
ThreadAbortExce ption will be sent through interop code.

Hmmm....

bill
"Ken Varn" <nospam> wrote in message
news:eH******** ********@TK2MSF TNGP10.phx.gbl. ..

At the level where the processing is being performed, I do not have access

to the Page.Response object. This is being done in a generic C++ DLL that is not ASP.NET aware. Is there any way that I can cancel an old

processing

thread on the next new request that comes in or are there any other
solutions?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
"John Timney (ASP.NET MVP)" <ti*****@despam med.com> wrote in message
news:OG******** ******@TK2MSFTN GP14.phx.gbl...

You could take a look at the isClientConnect ed property to see if it

helps.

http://msdn.microsoft.com/library/de...ectedTopic.asp

Its often useful to run this type of check in a serperate thread end
evaluate it alongside your executing long process, and work out a way to cancel the process if the client becomes disconnected.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"Ken Varn" <nospam> wrote in message
news:Ot******** ******@TK2MSFTN GP12.phx.gbl...
>I have an ASP.NET form that may take a very long time to process a
> particular request. If the user closes the browser window, the request > will
> continue to process until it completes. This is a problem when a user > tries
> to re-establish a new session. Since the previous request is still

being

> processed, the new request must now wait for it to complete. Is there > anyway to force old IIS processing thread sessions to terminate if they > are
> no longer active?
>
> --
> -----------------------------------
> Ken Varn
> Senior Software Engineer
> Diebold Inc.
>
> EmailID = varnk
> Domain = Diebold.com
> -----------------------------------
>
>

[William F. Robertson, Jr.]

Are you doing the long running process in your request thread? There is a
request timeout that is defaulted to 90 seconds and the thread will be
aborted by the runtime.

There are no problems with IIS calling the thread abort on a request thread.
Infact, it will return the thread to the request thread pool faster than
just letting it complete.

A couple things to consider with placing the Thread in Session:
It will only work with Session State InProc.
If the user uses the ctrl-n option, all browser windows will have the same
Session.

bill

"Ken Varn" <nospam> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

The C++ module is managed, so maybe what you are saying will work.

So let me get this straight on what you are suggestion. Store the
Thread.CurrentT hread in a Session variable, then on re-entry call the Abort method on the thread. I'll give that a shot. It sounds like it might work. Are there any adverse ramifications to IIS if I do this? I wasn't sure if
there was some standard ASP.NET call that I should make to abort an IIS
thread.

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
"William F. Robertson, Jr." <th****@nameht. org> wrote in message
news:%2******** *******@TK2MSFT NGP10.phx.gbl.. .

Could you not just save a reference to the Thread object that is performing

the lengthly operation, and when you need to cancel the thread, could

could

either signal the thread, but since you said it is interop, it might be

best

to call Thread.Abort() on it.

Actually now that I think about it, I am not sure in the
ThreadAbortExce ption will be sent through interop code.

Hmmm....

bill
"Ken Varn" <nospam> wrote in message
news:eH******** ********@TK2MSF TNGP10.phx.gbl. ..

At the level where the processing is being performed, I do not have access to the Page.Response object. This is being done in a generic C++ DLL that is not ASP.NET aware. Is there any way that I can cancel an old

processing

thread on the next new request that comes in or are there any other
solutions?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
"John Timney (ASP.NET MVP)" <ti*****@despam med.com> wrote in message
news:OG******** ******@TK2MSFTN GP14.phx.gbl...
> You could take a look at the isClientConnect ed property to see if it
helps.
>
>

http://msdn.microsoft.com/library/de...ectedTopic.asp

>
> Its often useful to run this type of check in a serperate thread end
> evaluate it alongside your executing long process, and work out a way to

> cancel the process if the client becomes disconnected.
>
> --
> Regards
>
> John Timney
> ASP.NET MVP
> Microsoft Regional Director
>
> "Ken Varn" <nospam> wrote in message
> news:Ot******** ******@TK2MSFTN GP12.phx.gbl...
> >I have an ASP.NET form that may take a very long time to process a
> > particular request. If the user closes the browser window, the

request

> > will
> > continue to process until it completes. This is a problem when a user > > tries
> > to re-establish a new session. Since the previous request is

still being
> > processed, the new request must now wait for it to complete. Is

there > > anyway to force old IIS processing thread sessions to terminate if

they

> > are
> > no longer active?
> >
> > --
> > -----------------------------------
> > Ken Varn
> > Senior Software Engineer
> > Diebold Inc.
> >
> > EmailID = varnk
> > Domain = Diebold.com
> > -----------------------------------
> >
> >
>
>

[Ken Varn]

Thanks for the info. I have increased the timeout in IIS to compensate for
the default delay.

I see your point on Session state. I should probably use Application state
instead.

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
"William F. Robertson, Jr." <th****@nameht. org> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

Are you doing the long running process in your request thread? There is a
request timeout that is defaulted to 90 seconds and the thread will be
aborted by the runtime.

There are no problems with IIS calling the thread abort on a request thread. Infact, it will return the thread to the request thread pool faster than
just letting it complete.

A couple things to consider with placing the Thread in Session:
It will only work with Session State InProc.
If the user uses the ctrl-n option, all browser windows will have the same
Session.

bill

"Ken Varn" <nospam> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

The C++ module is managed, so maybe what you are saying will work.

So let me get this straight on what you are suggestion. Store the
Thread.CurrentT hread in a Session variable, then on re-entry call the

Abort

method on the thread. I'll give that a shot. It sounds like it might

work.

Are there any adverse ramifications to IIS if I do this? I wasn't sure if

there was some standard ASP.NET call that I should make to abort an IIS
thread.

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
"William F. Robertson, Jr." <th****@nameht. org> wrote in message
news:%2******** *******@TK2MSFT NGP10.phx.gbl.. .

Could you not just save a reference to the Thread object that is

performing

the lengthly operation, and when you need to cancel the thread, could

could

either signal the thread, but since you said it is interop, it might be

best

to call Thread.Abort() on it.

Actually now that I think about it, I am not sure in the
ThreadAbortExce ption will be sent through interop code.

Hmmm....

bill
"Ken Varn" <nospam> wrote in message
news:eH******** ********@TK2MSF TNGP10.phx.gbl. ..
> At the level where the processing is being performed, I do not have

access

> to the Page.Response object. This is being done in a generic C++

DLL that

> is not ASP.NET aware. Is there any way that I can cancel an old
processing
> thread on the next new request that comes in or are there any other
> solutions?
>
> --
> -----------------------------------
> Ken Varn
> Senior Software Engineer
> Diebold Inc.
>
> EmailID = varnk
> Domain = Diebold.com
> -----------------------------------
> "John Timney (ASP.NET MVP)" <ti*****@despam med.com> wrote in message
> news:OG******** ******@TK2MSFTN GP14.phx.gbl...
> > You could take a look at the isClientConnect ed property to see if

it > helps.
> >
> >
>

http://msdn.microsoft.com/library/de...ectedTopic.asp

> >
> > Its often useful to run this type of check in a serperate thread end > > evaluate it alongside your executing long process, and work out a way

to

> > cancel the process if the client becomes disconnected.
> >
> > --
> > Regards
> >
> > John Timney
> > ASP.NET MVP
> > Microsoft Regional Director
> >
> > "Ken Varn" <nospam> wrote in message
> > news:Ot******** ******@TK2MSFTN GP12.phx.gbl...
> > >I have an ASP.NET form that may take a very long time to process a > > > particular request. If the user closes the browser window, the
request
> > > will
> > > continue to process until it completes. This is a problem when a user

> > > tries
> > > to re-establish a new session. Since the previous request is

still > being
> > > processed, the new request must now wait for it to complete. Is

there

> > > anyway to force old IIS processing thread sessions to terminate

if they
> > > are
> > > no longer active?
> > >
> > > --
> > > -----------------------------------
> > > Ken Varn
> > > Senior Software Engineer
> > > Diebold Inc.
> > >
> > > EmailID = varnk
> > > Domain = Diebold.com
> > > -----------------------------------
> > >
> > >
> >
> >
>
>