I am trying to write an application in VB.NET to process transactions that come down a phone line. As it is possible that one could follow closely on the heels of another, I don't want to have to wait for the first transaction to complete before starting to process the next.
Another programmer is writing the TAPI interface, and I have to provide a function that takes an input string as a parameter. What I need to do is to take the parameter and quickly send it to be processed so that if the function is called again the buffer can be dumped and sent to the called function again.
The MSDN help on threads seems to only help if I intend to run a number of different functions/subs at the same time, and doesn't cover wanting to run multiple instances of the same one.
If what you are using is really that processor intensive, I suggest you read up on the ThreadPool class. It can be passed a delegate to add to a queue of threads, managed by the system.
I haven't used this class yet myself so I can offer little more than the advice to look it up and see if it's appropriate for your needs.
Another possibility is to have a listening app that simply takes each message from the phone line and puts the data into a Message Queue. You can define a Message Queue Listener that calls a component that processes each message. If a message is sent to a Message Queue it can be guaranteed to get in the Queue so you won't have to worry about losing it. They're also very fast and made to handle stand-alone transactions that are meant to be asyncronous.
They're certainly not right for every situation, especially if you're have a huge volume of messages which might better be processed by your app. Since they can guarantee the message is sent or not sent as a whole unit AND they're async, they might work for what you want.
I haven't used them in .NET but I did in VB6 and they worked like a charm. If you want to investigate them I'd first check the .NET support for them. I know the MQ Triggers (the built-in service that called a component when a message arrived) were meant to call COM components. They may have other methods to call .NET assemblies, web services, etc. but I have no idea
Another, similar, alternative is web services. They don't have to be traditional over-the-internet. They could be internal only web services. The advantage they might bring is that they are asyncronous. So your listening app takes the message from the phone line and sends it off to a web service, asyncronously. I've used web services asyncronously and they work perfectly as well. I don't use them for updates (in async mode that is), but to pull down data in separate threads to speed up the pulling of lookup data, but they do work quite nicely.
Thanks for the suggestions, but they don't really help me here. Perhaps I didn't give enough details.
Another programmer is dealing with getting the information, and I have to deal with sending each message to be processed, but it has to be possible for a new message to be processed before a previous one finishes to avoid the system coming to a standstill if any third-party systems don't return a message.
I have tried using System.ThreadPool, but it seems to cater for running different program objects at the same time. What I want to do is to run multiple instances of the same class/subroutine or whatever.
I think the suggestions would still work. Let me see if I understand and can re-explain.
It sounds like your app is handling all messages from someone else's piece. You want your app to process each message but not worry about stalling on each message since the processing isn't necessarily something that will complete fast enough. So you're trying to utilize threads to keep your app from stalling on one message.
What I was suggesting was that you would have two apps. One would grab messages from your friend's and put the messages in a queue (for example). The Message Queue would instantiate another app, written by you. It would do this for every message it received. This means your second app may get instantiated multiple times (obviously, each one would be in a separate thread - a separate process in fact). Each instance would handle one message only so it wouldn't matter if it stalled.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
