G
Guest
My asp.net application depends on obtaining allot of data from a remote
application. This application is a bit of a monster and it is not an option
to install it on the asp.net system. Note - the remote application is
developed in vb6
Currently I have the application installed on a number of remote computers
and use DCOM from asp.net to communicate with this application. All the
calls to this remote application are generally kept to a minimum - ie - one
function call that passes the many parameters. This works reasonably well.
The remote system cannot be depended upon to always work - the remote
application has a tendency to crash or get tied up for long periods doing
processing.
To deal with this I created a vb6 exe called ManageConnections. asp.net
calls this application and this application keeps a track of the references
to the different machines running the remote application. When an asp.net
session needs to call the remote application it makes a request to
ManageConnections and manage connections returns a direct reference to one of
the remote machines. The asp.net session will than make calls direct to the
remote application without going through the ManageConnections application.
ManageConnections will every few seconds test to see if the remote
application is still responsive - if they stop responding than it will
destroy the reference to the remote machine and not give this reference to a
new page. (any pages currently using this reference are possibly in trouble).
This testing to check if remote machines are still running is done using a
different thread to prevent the ManageConnections from been unresponsive to a
new asp.net call.
I have no experience in undertaking this type of setup. Does the way I have
set this up sound reasonable - or is there a major flaw in the reasoning. Is
vb6 able to do this type of work?? I have tried to use threading within vb6
to prevent lock-ups - will this work - or will there still be the possibility
of the system been blocked - due to DCOM or because of out-of-process calls
between asp.net and ManageConnections???
Obviously this system could still fail - but the main idea of this
implementation was to limit the chances of a asp.net request hanging or
timeing out due to a non responsive remote application.
Would I be better off creating ManageConnections in vb.net?? I have little
experience in this area - but I would guess the advantages would be in thread
management and the polling of the remote application.
To date this system has only been tested on 3-4 users and appears to be
working - but this will grow in the coming 12 months to 50-100 users and I
need to make sure the system will be stable before this happens.
Anyone with experience in doing something like this?? Any help would be
appreciated.
application. This application is a bit of a monster and it is not an option
to install it on the asp.net system. Note - the remote application is
developed in vb6
Currently I have the application installed on a number of remote computers
and use DCOM from asp.net to communicate with this application. All the
calls to this remote application are generally kept to a minimum - ie - one
function call that passes the many parameters. This works reasonably well.
The remote system cannot be depended upon to always work - the remote
application has a tendency to crash or get tied up for long periods doing
processing.
To deal with this I created a vb6 exe called ManageConnections. asp.net
calls this application and this application keeps a track of the references
to the different machines running the remote application. When an asp.net
session needs to call the remote application it makes a request to
ManageConnections and manage connections returns a direct reference to one of
the remote machines. The asp.net session will than make calls direct to the
remote application without going through the ManageConnections application.
ManageConnections will every few seconds test to see if the remote
application is still responsive - if they stop responding than it will
destroy the reference to the remote machine and not give this reference to a
new page. (any pages currently using this reference are possibly in trouble).
This testing to check if remote machines are still running is done using a
different thread to prevent the ManageConnections from been unresponsive to a
new asp.net call.
I have no experience in undertaking this type of setup. Does the way I have
set this up sound reasonable - or is there a major flaw in the reasoning. Is
vb6 able to do this type of work?? I have tried to use threading within vb6
to prevent lock-ups - will this work - or will there still be the possibility
of the system been blocked - due to DCOM or because of out-of-process calls
between asp.net and ManageConnections???
Obviously this system could still fail - but the main idea of this
implementation was to limit the chances of a asp.net request hanging or
timeing out due to a non responsive remote application.
Would I be better off creating ManageConnections in vb.net?? I have little
experience in this area - but I would guess the advantages would be in thread
management and the polling of the remote application.
To date this system has only been tested on 3-4 users and appears to be
working - but this will grow in the coming 12 months to 50-100 users and I
need to make sure the system will be stable before this happens.
Anyone with experience in doing something like this?? Any help would be
appreciated.