S
Stephen Barrett
I really hope someone can give me some ideas. Sorry for the long post.
Problem (Using .Net 1.1):
We have a current asp.net application that a user uses to submit work and
when it is finished view the results. It is implemented using .net
remoting. The user submits a form which in turn calls to our application
tier via .Net remoting, which in turn does the work and returns the results.
This works find now when requests aren't that many. The problem is that the
app server that does this specialized work can only really handle x number
of concurrent requests at a time due to hardware. In the current
configuration, the requests are unbounded so if too many concurrent requests
are made, the server has major issues.
For larger work requests, i.e. long running, requests are queued up and the
users periodically check for completeion. These larger requests could take
many many hours. When the request is made, the app tier simply drops the
request into a queue which is monitored by 1 or more servers that actually
process the work.
I have been requested to make the small individual requests that need to
wait on data work in a queued manner, but it still needs to return the data
on the call. That is, it needs to look syncronous to the web application.
Basically the request call needs to queue the request, wait for the request
to be picked up by a server and processed to completion. Having the web
page contantly refresh to poll for a status of complete is not allowed. To
the web app, it has to look and feel exactly the way it currently does. All
the magic has to happen on the app server.
I have no problem getting the message queued. I thought about having the
object that is called via remoting queue to the request and then poll an
internal object checking on when the item is finished. It would sleep for a
millisecond within the loop just to free up cpu for other processing.
The preferred method would be to use some kind of event / delegate handling.
I would like for the remoted object to simple call a method on the "manager"
class that maintains the queueu and statuses and block until the "manager"
class says it is finished. This should be easy with a Begin/End invoke
paradigm, but that assumes the "manager" class method that is called starts
and finishes. It won't finish until the manager receives a completion
message via an MSMQ message. The manager currently has a separate thread
that is dedicated to receiving messages from the queue.
So basically when the manager receives a completion message via the msmq, it
should send the result to the original thread that initiated the request.
How does it unblock the requesting thread in the calling object?
Hope this makes sense enough for some suggestions.
Problem (Using .Net 1.1):
We have a current asp.net application that a user uses to submit work and
when it is finished view the results. It is implemented using .net
remoting. The user submits a form which in turn calls to our application
tier via .Net remoting, which in turn does the work and returns the results.
This works find now when requests aren't that many. The problem is that the
app server that does this specialized work can only really handle x number
of concurrent requests at a time due to hardware. In the current
configuration, the requests are unbounded so if too many concurrent requests
are made, the server has major issues.
For larger work requests, i.e. long running, requests are queued up and the
users periodically check for completeion. These larger requests could take
many many hours. When the request is made, the app tier simply drops the
request into a queue which is monitored by 1 or more servers that actually
process the work.
I have been requested to make the small individual requests that need to
wait on data work in a queued manner, but it still needs to return the data
on the call. That is, it needs to look syncronous to the web application.
Basically the request call needs to queue the request, wait for the request
to be picked up by a server and processed to completion. Having the web
page contantly refresh to poll for a status of complete is not allowed. To
the web app, it has to look and feel exactly the way it currently does. All
the magic has to happen on the app server.
I have no problem getting the message queued. I thought about having the
object that is called via remoting queue to the request and then poll an
internal object checking on when the item is finished. It would sleep for a
millisecond within the loop just to free up cpu for other processing.
The preferred method would be to use some kind of event / delegate handling.
I would like for the remoted object to simple call a method on the "manager"
class that maintains the queueu and statuses and block until the "manager"
class says it is finished. This should be easy with a Begin/End invoke
paradigm, but that assumes the "manager" class method that is called starts
and finishes. It won't finish until the manager receives a completion
message via an MSMQ message. The manager currently has a separate thread
that is dedicated to receiving messages from the queue.
So basically when the manager receives a completion message via the msmq, it
should send the result to the original thread that initiated the request.
How does it unblock the requesting thread in the calling object?
Hope this makes sense enough for some suggestions.