Wednesday, January 28, 2004 11:22:26 PM
"... refuse to believe the problem is [hardware] new server
... If it were a problem with the machine itself,
it shouldn't be just ASP that's shutting down.
Granted, ASP is the busiest job it's running,
but plenty of other stuff is running on it 100% stable."
Disclaimer: Follows are just my mind farts.
ASP is not hardware,
but a software program loaded into memory.
Once running in memory,
does it use Windows 3.1 type .DLL(s) that you can obtain
the source code for and rebuild to insert breakpoints to
cause dumping of a file that includes status of whatever
you wish you knew of at certain points, like event logging,
but to a file that you can examine using a program that
knows the internal format used, and displays time wise
certain conditions you only now are assuming, but don't
really know, especially since that info ain't logged or displayed.
(echoed from top)
"... If it were a problem with the machine itself,
it shouldn't be just ASP that's shutting down..."
While I'am totally clueless on what ASP is or does,
and don't need to know,
but it supplies an important service to allow iHub to function,
but most likely it receives information from other software
that is running, and most likely works upon that and then
transmits the worked-on info to other software.
ok,
So far it is only ASP that dies.
For sure its extremely poorly dsigned software that will
decide to stop working, aka dies, and not report (log)
the routine/line aka error condition.
Hard for me to believe that is the case here,
as error handling is knowned to be hand-in-hand
with coding the functionality, and a die or stop of software
then is a condition of a hang, where the ASP here would
be inside an endless loop continuously doing nothing
that can be determine by the outside.
So, question:
When ASP dies/stops is it still running,
or has it crashed and done a fatal without reporting an error?
Next question:
Can another program running,
that is in communication with ASP,
either to give and report status,
or actually perform work between them two,
can that other program tell ASP that something is wrong
to a degree that you(ASP) better stop before things
really get messed up.
If so, can question:
When ASP is "told" to stop
either normally or through an exception taken elsewhere,
does ASP log that event of stopping itself using what
should be its routine for a normal shutdown versus when
itself takes a shutdown from an error condition itself
has encountered and cannot deal with or fix?
Asking two question:
(1)
Can ASP execute a shutdown procedure by receiving
a command from another running program that took
an exception bad enough that it knows that ASP needs
to be stopped, else system corruption can occur.
(2)
If ASP can be told to shut itself down, with the command
either being generated internally or externally,
will that shutdown generate first a message stating the
where and why and what that caused the shutdown,
or will it simply do so without saying anything to the operator?
The efforts of you and Matt to change code without reasons
derived from debugging the code that identifies error conditions
that signal exceptions taken... not professional.
Code like other machines do only what you tell it to do,
and since sometimes we tell it to do things we meant not to,
then its up to the coder to put into the code the ability for
the code to tell the coder exectually what it has or is doing.
Near impossible for you or anyone else to read the sources
if its multi-threaded with unlimited stress conditions possible.
debugger - breakpoints - dumps
I'll bet ASP has these extra features in the Delux version,
or another debug version is available to be purchased
that is run only to locate bad bugs.
Great and wonderful if your experience to "smell"
where the problem is, and it gets fixed by monday,
but if not, then you need ASP to tell what "why" it dies.
... If it were a problem with the machine itself,
it shouldn't be just ASP that's shutting down.
Granted, ASP is the busiest job it's running,
but plenty of other stuff is running on it 100% stable."
Disclaimer: Follows are just my mind farts.
ASP is not hardware,
but a software program loaded into memory.
Once running in memory,
does it use Windows 3.1 type .DLL(s) that you can obtain
the source code for and rebuild to insert breakpoints to
cause dumping of a file that includes status of whatever
you wish you knew of at certain points, like event logging,
but to a file that you can examine using a program that
knows the internal format used, and displays time wise
certain conditions you only now are assuming, but don't
really know, especially since that info ain't logged or displayed.
(echoed from top)
"... If it were a problem with the machine itself,
it shouldn't be just ASP that's shutting down..."
While I'am totally clueless on what ASP is or does,
and don't need to know,
but it supplies an important service to allow iHub to function,
but most likely it receives information from other software
that is running, and most likely works upon that and then
transmits the worked-on info to other software.
ok,
So far it is only ASP that dies.
For sure its extremely poorly dsigned software that will
decide to stop working, aka dies, and not report (log)
the routine/line aka error condition.
Hard for me to believe that is the case here,
as error handling is knowned to be hand-in-hand
with coding the functionality, and a die or stop of software
then is a condition of a hang, where the ASP here would
be inside an endless loop continuously doing nothing
that can be determine by the outside.
So, question:
When ASP dies/stops is it still running,
or has it crashed and done a fatal without reporting an error?
Next question:
Can another program running,
that is in communication with ASP,
either to give and report status,
or actually perform work between them two,
can that other program tell ASP that something is wrong
to a degree that you(ASP) better stop before things
really get messed up.
If so, can question:
When ASP is "told" to stop
either normally or through an exception taken elsewhere,
does ASP log that event of stopping itself using what
should be its routine for a normal shutdown versus when
itself takes a shutdown from an error condition itself
has encountered and cannot deal with or fix?
Asking two question:
(1)
Can ASP execute a shutdown procedure by receiving
a command from another running program that took
an exception bad enough that it knows that ASP needs
to be stopped, else system corruption can occur.
(2)
If ASP can be told to shut itself down, with the command
either being generated internally or externally,
will that shutdown generate first a message stating the
where and why and what that caused the shutdown,
or will it simply do so without saying anything to the operator?
The efforts of you and Matt to change code without reasons
derived from debugging the code that identifies error conditions
that signal exceptions taken... not professional.
Code like other machines do only what you tell it to do,
and since sometimes we tell it to do things we meant not to,
then its up to the coder to put into the code the ability for
the code to tell the coder exectually what it has or is doing.
Near impossible for you or anyone else to read the sources
if its multi-threaded with unlimited stress conditions possible.
debugger - breakpoints - dumps
I'll bet ASP has these extra features in the Delux version,
or another debug version is available to be purchased
that is run only to locate bad bugs.
Great and wonderful if your experience to "smell"
where the problem is, and it gets fixed by monday,
but if not, then you need ASP to tell what "why" it dies.
Lactose Free Milkman
Discover What Traders Are Watching
Explore small cap ideas before they hit the headlines.
