Leftovers

OK, so I've got this beast of a project left over from someone else's "Let's learn VB" party. 

The beast does it's job, however it's a b*tch to maintain and we're having problems when it's under load.

The reason for the problem is that it has to listen to approximately 130 network events/s from 4 different servers, plus commands from the GUI (which resides in a seperate process), all while trying to log results (synchronously) to a DB Server.

Problem: SetTimer is used to re-enter into the server process (Activex-Exe) after a method call from the GUI, but sometimes the timer does not go off.  I think that this is because posting of results to the DB is blocking the thread, so that's the first thing I'm changing.

However,  I'm curious if anyone can elaborate on what the issue with SetTimer might be.  I've read that SetTimer also shouldn't be used in a Windows Service (although, this proj. isn't one).

SetTimer relies on window messages right?  Is that why it can't be used in a service?  Aren't window messages supposed to be held in a queue until the target window can get to them?

Whiner
Monday, March 29, 2004

Sounds like you need to scrap it all and start over.  Tell your bosses I said it was OK.

Ugnonimous
Monday, March 29, 2004

We are doing it over, but I am curious about how SetTimer works.

Whiner
Monday, March 29, 2004

Ah...so the next guy gets to say "I've got this beast of a project from someone else's `Let's learn SetTimer' party"...

.
Monday, March 29, 2004

Timers work just fine in services, BUT you may have to allow it to interact with the desktop in order to use regular window timers. Normally you don't want to do this, but it depends on what kind of service you are making, and why you are making the program a service.

If window timers don't work, maybe waitable timers will work for you.

sid6581
Monday, March 29, 2004

I'm confused. Where does the timer fit into this?

Surely your code is event/interrupt driven?

You don't state the time period over which these 130 events occur, nor what processing occurs for each.

The DB logging is what will absolutely kill performance. My advice would be to create a separate app (service?) to handle that and talk to it using either Windows messaging, MSMQ or just create flat files in a specific directory for it to pick up.

If you're going to rewrite it:
Get the DB logging stuff out, and make it either asynch or very, very quick.
Think about how you're going to administer it (possibly remotely)

Justin
Tuesday, March 30, 2004

The project in question is an AxExe server that is instantiated by a Standard Exe gui project.  When the gui calls a server method, the server saves the parameters and sets a timer that re-enters to do the real work.

The timer period for 130 events is approximately one second (OP says 130 events/s).

Yep, the DB stuff is being done asynch now.  That solves most of the immediate problems, however before the DB stuff was asynch, timers were not being caught and I was just wondering why that could be.

I figured it out.  The problem was the existence of a MsgBox that was raised from inside AxExe server. It had nothing to do with the DB stuff (although the synchronous DB stuff was causing other problems like blocking the whole thread).

Oh, and "." that's very funny but I think the next person who get's this project will more likely want to kiss me.

Whiner
Tuesday, March 30, 2004

>The project in question is an AxExe server that is
>instantiated by a Standard Exe gui project. 
>When the gui calls a server method, the server saves the
>parameters and sets a timer that re-enters
>to do the real work.

There's no right way of doing this, but my favourite would be creating a service to process the GUI requests and a service or "AxServer" to handle both these and standard events. You can communicate between your service and main project using either windows messaging or winsock (better, because it fits in with the event handling architecture.

>The timer period for 130 events is approximately one
>second (OP says 130 events/s).
So it does. You're quite right. Even so, shouldn't be a problem unless you have some process intensive activity behind the events.

>I figured it out.  The problem was the existence of a
>MsgBox that was raised from inside AxExe server. It had
>nothing to do with the DB
Make sure you have "unattended execution" set. May be worth doing a global search/replace for MsgBox and replacing it with your own function - e.g. one that does App.Log instead

Best of luck with it.

Justin
Wednesday, March 31, 2004

Thank you Justin

Whiner
Thursday, April 1, 2004

  Recent Topics

  Fog Creek Home