activex lifetime?

[fantum]

I have created a small activex dll to do a background task on my web server. I
fire it off with a set myjob = server.createobject(myactivex) and it runs.

I do not do a set myjob = nothing and so it seems to keep working even after
the initiating session is closed with session.abandon.

Question... what will be the lifetime of this object and is there a way to tell
if it is dead and needs to be reset... after the session is abandoned I no
longer have a reference to it (myjob)

TIA

 

[Anthony Jones]

I have created a small activex dll to do a background task on my web server. I
fire it off with a set myjob = server.createobject(myactivex) and it runs.

So the myactivex creates it's own thread to do the work in does it?
If not then server.createobject blocks at this point, the request never
finishes and any code following it never runs.

I do not do a set myjob = nothing and so it seems to keep working even after
the initiating session is closed with session.abandon.

This code is probably not ever executed anyway. Avoiding set myobj =
nothing wouldn't help it would be released at the end of the request anyway.
Session.abandon is irrelevant.

Question... what will be the lifetime of this object and is there a way to tell
if it is dead and needs to be reset... after the session is abandoned I no
longer have a reference to it (myjob)

Until the process in which it is created is terminated.

ASP is not a good place to be performing 'background' tasks. That's what
services are for.

 

[fantum]

i would have thought as you stated but...

the process (dll) DOES launch from asp... only setting the activex object =
nothing in the same session stops it... session abandon does not.

i have verified the above and the process is still running (on the server)
after several hours (verified)

now i need to find it and stop it...

any ideas?

 

[Anthony Jones]

i would have thought as you stated but...

the process (dll) DOES launch from asp... only setting the activex object =
nothing in the same session stops it... session abandon does not.

More code needed since what you are saying doesn't appear to make any sense.

Take a look at this one liner:-

<%
Dim o: Set o = Server.CreateObject("MyLib.MyClass")
%>

When a request is made to this page an instance of MyLib.MyClass is created.
Now that request is finished, despite that a session has been created and
still exists, the variable o is destroyed, if it contains a reference to an
object that reference will be released.

What you seem to be saying is that this component not only is it clever
enough to spin up another thread to do the background task but is also
sensitive to whether VBScript code assigns a nothing to the variable that
received the reference as opposed to it being done automatically when the
script context is torn down.

Session.Abandon is irrelevent all that does is destroy the session object
and any of it's contents. It doesn't affect the currently running script.

i have verified the above and the process is still running (on the server)
after several hours (verified)

Is it a seperate process that is spun up then?

 

[fantum]

I know it seems strange but that is what is happening and the reason for this
query.

I included the simple asp code below and the CMSComm is a simple activex based
om the MSComm control.

I put a timer in the CMSComm to write a line to the log every 10 minutes and it
has been reporting for hours.

So far the only way I have found to turn it off is to restart IIS.

It is doing *exactly* what I need but being the curious type I want to know why
it is not working the way I expected which is the way you describe.

yabba

<%
dim x, temp, port, comm, wait, count
dim logPath, logName, bufferPath, bufferName
on error resume next

port = 1
session.timeout = 1
logName = "CMSComm.log"
bufferName = "cmscomm.txt"
logPath = server.mapPath("../Logs") & "\"
bufferPath = server.mapPath("../Files") & "\"
set comm = nothing
set comm = createObject("CMSComm.comm")
response.write(now & "<br>")
temp = comm.commVersion
if err <> 0 then
response.write "CMSComm not found<br>"
response.end
end if
response.write "CMSComm version " & temp & "<br>"
comm.setLog = logPath & logName
'call comm.clearLog()
comm.setBuffer = bufferPath & bufferName
'call comm.clearBuffer()
call comm.commClose(0)
call comm.commOpen(0, port)
session.abandon
response.end
%>

 

[Anthony Jones]

I know it seems strange but that is what is happening and the reason for this
query.

I included the simple asp code below and the CMSComm is a simple activex based
om the MSComm control.

I put a timer in the CMSComm to write a line to the log every 10 minutes and it
has been reporting for hours.

So far the only way I have found to turn it off is to restart IIS.

It is doing *exactly* what I need but being the curious type I want to know why
it is not working the way I expected which is the way you describe.

yabba

<%
dim x, temp, port, comm, wait, count
dim logPath, logName, bufferPath, bufferName
on error resume next

port = 1
session.timeout = 1
logName = "CMSComm.log"
bufferName = "cmscomm.txt"
logPath = server.mapPath("../Logs") & "\"
bufferPath = server.mapPath("../Files") & "\"
set comm = nothing
set comm = createObject("CMSComm.comm")
response.write(now & "<br>")
temp = comm.commVersion
if err <> 0 then
response.write "CMSComm not found<br>"
response.end
end if
response.write "CMSComm version " & temp & "<br>"
comm.setLog = logPath & logName
'call comm.clearLog()
comm.setBuffer = bufferPath & bufferName
'call comm.clearBuffer()
call comm.commClose(0)
call comm.commOpen(0, port)
session.abandon
response.end
%>

What happens if you replace session.abandon with Set comm = Nothing do logs
stop coming? How about when you remove the final response.end?

At a guess you have a hidden VB6 form on which a MSComm control is sited.
Forms and activeX controls only run in the processes main thread. Hence the
worker thread is able to return control back to your script. The events
coming from the MSComm control will be processed in the main thread. Unless
you build some way to communicate that the form should unload into this
activeX control you only way to kill it is to shutdown the process in which
it runs.

I dread to think what sort of things might go wrong with this. It would be
unreasonable to expect IIS developers to have anticipated VB6 forms running
in the main thread.

i would have thought as you stated but...

the process (dll) DOES launch from asp... only setting the activex

object
=

nothing in the same session stops it... session abandon does not.

More code needed since what you are saying doesn't appear to make any sense.

Take a look at this one liner:-

<%
Dim o: Set o = Server.CreateObject("MyLib.MyClass")
%>

When a request is made to this page an instance of MyLib.MyClass is created.
Now that request is finished, despite that a session has been created and
still exists, the variable o is destroyed, if it contains a reference to an
object that reference will be released.

What you seem to be saying is that this component not only is it clever
enough to spin up another thread to do the background task but is also
sensitive to whether VBScript code assigns a nothing to the variable that
received the reference as opposed to it being done automatically when the
script context is torn down.

Session.Abandon is irrelevent all that does is destroy the session object
and any of it's contents. It doesn't affect the currently running script.

i have verified the above and the process is still running (on the server)
after several hours (verified)

Is it a seperate process that is spun up then?

now i need to find it and stop it...

any ideas?

 

[fantum]

snip---

What happens if you replace session.abandon with Set comm = Nothing do logs
stop coming? How about when you remove the final response.end?

yes, that is the way i usually stop an activex

At a guess you have a hidden VB6 form on which a MSComm control is sited.
Forms and activeX controls only run in the processes main thread. Hence the
worker thread is able to return control back to your script. The events
coming from the MSComm control will be processed in the main thread. Unless
you build some way to communicate that the form should unload into this
activeX control you only way to kill it is to shutdown the process in which
it runs.

yes, there is a vb6 form that holds the MSComm control but i never show it...
the activex publics are in a class and i call thse to do stuff with the
control.

I dread to think what sort of things might go wrong with this.

for instance?

It would be

unreasonable to expect IIS developers to have anticipated VB6 forms running
in the main thread.