[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 241
  • Last Modified:

Timeout STA object from worker thread

This issue has been driving me nuts for a very long time - thus, I'm willing to give a ton of points to whomever helps me get this solved correctly...  I tried to give more than 500, but this site won't let me.  However, if someone has an idea how to get around that limitation that works, I'm willing to give 1500 - 2000 points if I get a working answer, in a very timely manner.  Anyway, on to the problem...

I have an object that is connecting to a middle tier (at the very base it is a SQL Server farm, but that is very much abstracted at this level of interaction).  Now, the problem is the performance is horrible & sporadic.  For instance, sometimes it will be fully connected in under 1.5 seconds, other times it can take up to 4 or 5 minutes.  The problem is that users are constantly opening bugs/raising support issues because of these long connection times - so I need to give hte users the ability to cancel the connection if it starts taking too long.

My proposed solution:
1) Start timer (delay 2 seconds first in case it connect quickly - give it a chance first, so to speak)
2) Attempt to connect

In the timer callback, which after the initial 2 seconds will fire every 1 second do:
1) If not your first time, skip to step 3.
2) Pop up a progress dialog that has a cancel button
3) Increment the progress dialog with the current amount of timet aking to connect (+1 on the progress UI tick)

Within the progress dialog:
1) if user does nothing, just continue being updated by the timer that is running - no big deal
2) If a user hits 'Cancel' to cancel the connection b/c it is taking too long, we need to cancel the connection on the main thread --> this is the problem!!

Obviously, throwing an exception in that case will not work since it will be happening in a child thread - the exception will never make it back to the main thread since they are not in the same stack.

Limitation:
1) The object that is doing the connection is from the OM exposed/created for this middle tier system.  It is STA and completely non-thread safe.  Therefore, I cannot create the connection in a worker thread and then pass it back to the main thread - it will throw exxceptions and bring down the sytstem when you try to use it.  I have no control over that object's implementation and therefore have no way of having it updated to be thread safe.
2) The object connecting also does not expose anyway to set a predeterimined amount fo time before timing out (like a normal SQL server connection attempt allows you to do).  Again, I have no control over this - I must use it the wya it is.
3) The connection object will eventually timeout on its own from the middle tier & return an exception to me, but it is undeterministic - sometimes within 30 seconds, sometimes it can take up to 10 mintues or more - a very bad user experience since it makes the entire app look hung.


Does anyone have an idea of how to fix this?  How can I make a way for my users to cancel this operation.  I am doing this all in C#.  Thanks ahead of time for trying to help!
0
slapiwite
Asked:
slapiwite
  • 3
  • 3
1 Solution
 
gregoryyoungCommented:
Thread.Abort will cause an exception in the child ... you already know in the parent that this is occurring am I missing something?

Greg
0
 
slapiwiteAuthor Commented:
The problem is I need a way to get a child thread to cancel an operation in the main thread - I don't care about crashing the child thread because that does me no good; I have to have the connection made on the main thread.

I've talked to Jeffrey Richter, and he says that it isn't possible to do what I'm trying to do.  So, unless anyway has any ideas of how to get something like this working, I think it might be fruitless...
0
 
gregoryyoungCommented:
you say you cannot create the connection in a child thread then pass it back to the mian thread ...

Would it be possible to have the main thread start the child thread, have it connect, complete the operation .... while having the main thread watch it ? this would make it easily cancellable.

Greg
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
slapiwiteAuthor Commented:
No, the object (that needs to connect) is not thread safe - so I cannot create it on a thread then use it on another one.  That means that hte main thread needs to create the object and since a child thread can't interupt the main thread I guess this has no solution.  The only alternative would be to create the object on the child thread and only use it from taht thread - meaning all work happens there) - but that would be a very fundamental design change to the current system and too late to change it (not to mention would be very painful to have to do that constnatly).

I guess that's it - unless you have something else?  I'll give you some points if I am allowed for at least trying (no one else even responded).
0
 
gregoryyoungCommented:
That is exactly what I suggested (only using it within a child thread then aborting the child if need be). If that is a fundamental design change I would need to know more of your design to help.

0
 
slapiwiteAuthor Commented:
That would be too big of a change ot make at this point (need different plug-ins within the framework to be able to message requests/responses from the different threads connection to different middle tier objects, etc.  Perhaps in a future version I cna take the time to implement that approach.

I'm giving you the points for trying/responding.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now