Reentrant (?) Console Application....

[carlbono]

I need a way for my console application to stay running and be able to
be called at any time with some parameters, do it's work, then wait to
be called again, repeat.

Here's the details:

I have a C# engine that's used to run a lot of complex financial
calculations and return a report based upon the calculated results. My
program is called by another program... let's just call it "MasterApp"
and i'll call my program "Calc". Calc is the console app exe.

Here's the basic process:
1. User inputs some data into MasterApp.
2. User clicks tells MasterApp to "Go".
3. MasterApp writes out an xml file, then launches "Calc.exe"
4. Calc reads the xml to create the inputs that it understands
(there's some translation there).
5. Calc calls some of it's own dlls (C#), etc. with the translated
inputs.
6. The "guts" of calc.exe (the dlls which are called) take the inputs,
pull the data it needs, calculates and returns a report.
7. The report is written to a directory specified as a paramater to
the calc.exe call.
8. Calc closes.
9. MasterApp waits for Calc.exe to close, then displays the report to
the user.

The real issue here is performance. It's taking way too long to load
everything that's need into memory to run each time (JIT, etc.) and
then close everything back down EVERY time the user runs a report. I'd
like somehow, once the system is run the first time, for it to stay in
memory so that the user does not experience the load time lag every
single time they run a report.

As a note, loading the assemblies into the GAC doesn't appear to help.

I'll go ahead and apologize up front, because I am not certain that i'm
using the correct terminology to describe the issue i'm trying to
resolve.

Thanks in advance for any help/advice you can give.

- Carl

[billr]

I'm not sure I understand the choice of architecture here ...

Is there a NEED for calc.exe to be a command window application?
Can't you package your business logic (i.e.calc.exe) in a dll and call from
a web service, or package as a COM+ application, etc.
--
Of all words of tongue and pen, the saddest are: "It might have been"

Bill.Richards @ greyskin .co .uk
http://greyskin.co.uk
"ca******@gmail.com" wrote:

I need a way for my console application to stay running and be able to
be called at any time with some parameters, do it's work, then wait to
be called again, repeat.

Here's the details:

I have a C# engine that's used to run a lot of complex financial
calculations and return a report based upon the calculated results. My
program is called by another program... let's just call it "MasterApp"
and i'll call my program "Calc". Calc is the console app exe.

Here's the basic process:
1. User inputs some data into MasterApp.
2. User clicks tells MasterApp to "Go".
3. MasterApp writes out an xml file, then launches "Calc.exe"
4. Calc reads the xml to create the inputs that it understands
(there's some translation there).
5. Calc calls some of it's own dlls (C#), etc. with the translated
inputs.
6. The "guts" of calc.exe (the dlls which are called) take the inputs,
pull the data it needs, calculates and returns a report.
7. The report is written to a directory specified as a paramater to
the calc.exe call.
8. Calc closes.
9. MasterApp waits for Calc.exe to close, then displays the report to
the user.

The real issue here is performance. It's taking way too long to load
everything that's need into memory to run each time (JIT, etc.) and
then close everything back down EVERY time the user runs a report. I'd
like somehow, once the system is run the first time, for it to stay in
memory so that the user does not experience the load time lag every
single time they run a report.

As a note, loading the assemblies into the GAC doesn't appear to help.

I'll go ahead and apologize up front, because I am not certain that i'm
using the correct terminology to describe the issue i'm trying to
resolve.

Thanks in advance for any help/advice you can give.

- Carl

[billr]

I'm not sure I understand the choice of architecture here ...

Is there a NEED for calc.exe to be a command window application?
Can't you package your business logic (i.e.calc.exe) in a dll and call from
a web service, or package as a COM+ application, etc.
--
Of all words of tongue and pen, the saddest are: "It might have been"

Bill.Richards @ greyskin .co .uk
http://greyskin.co.uk
"ca******@gmail.com" wrote:

I need a way for my console application to stay running and be able to
be called at any time with some parameters, do it's work, then wait to
be called again, repeat.

Here's the details:

I have a C# engine that's used to run a lot of complex financial
calculations and return a report based upon the calculated results. My
program is called by another program... let's just call it "MasterApp"
and i'll call my program "Calc". Calc is the console app exe.

Here's the basic process:
1. User inputs some data into MasterApp.
2. User clicks tells MasterApp to "Go".
3. MasterApp writes out an xml file, then launches "Calc.exe"
4. Calc reads the xml to create the inputs that it understands
(there's some translation there).
5. Calc calls some of it's own dlls (C#), etc. with the translated
inputs.
6. The "guts" of calc.exe (the dlls which are called) take the inputs,
pull the data it needs, calculates and returns a report.
7. The report is written to a directory specified as a paramater to
the calc.exe call.
8. Calc closes.
9. MasterApp waits for Calc.exe to close, then displays the report to
the user.

The real issue here is performance. It's taking way too long to load
everything that's need into memory to run each time (JIT, etc.) and
then close everything back down EVERY time the user runs a report. I'd
like somehow, once the system is run the first time, for it to stay in
memory so that the user does not experience the load time lag every
single time they run a report.

As a note, loading the assemblies into the GAC doesn't appear to help.

I'll go ahead and apologize up front, because I am not certain that i'm
using the correct terminology to describe the issue i'm trying to
resolve.

Thanks in advance for any help/advice you can give.

- Carl

[C_Bone]

Sorry, I should have clarified things a little better....

Calc.exe is really a wrapper around our existing core business and
calculations logic (which exists in a series of C# dll assemblies).

The whole thing is a stand alone desktop application, so a web service
wouldn't work. All of our code is C#, so i'm not sure how/if a COM+
app would work.

The MasterApp program will only communicate with an exe. MasterApp
writes its output to a directory, calls calc.exe with a couple of
command line parameters (location of its output, etc), then waits for
calc.exe to exit.

I hope i've answered your questions.

I great appreciate your response.
- Carl.

[C_Bone]

Sorry, I should have clarified things a little better....

Calc.exe is really a wrapper around our existing core business and
calculations logic (which exists in a series of C# dll assemblies).

The whole thing is a stand alone desktop application, so a web service
wouldn't work. All of our code is C#, so i'm not sure how/if a COM+
app would work.

The MasterApp program will only communicate with an exe. MasterApp
writes its output to a directory, calls calc.exe with a couple of
command line parameters (location of its output, etc), then waits for
calc.exe to exit.

I hope i've answered your questions.

I great appreciate your response.
- Carl.

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Sorry, I should have clarified things a little better....

Calc.exe is really a wrapper around our existing core business and
calculations logic (which exists in a series of C# dll assemblies).

The whole thing is a stand alone desktop application, so a web service
wouldn't work. All of our code is C#, so i'm not sure how/if a COM+
app would work.

The MasterApp program will only communicate with an exe. MasterApp
writes its output to a directory, calls calc.exe with a couple of
command line parameters (location of its output, etc), then waits for
calc.exe to exit.

I hope i've answered your questions.

I great appreciate your response.
- Carl.

I would suggest in-proc remoting, that is, let the master application create
a separate Application Domain (AD) that handles the core business (so
you'll have to load the assemblies in that domain). The master application
can pass the XML as an argument in a (asynchronous) remoting call that
starts the business process, let the 'report' be the return 'value' of the
call, or use a call-back when done.

Willy.

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Sorry, I should have clarified things a little better....

Calc.exe is really a wrapper around our existing core business and
calculations logic (which exists in a series of C# dll assemblies).

The whole thing is a stand alone desktop application, so a web service
wouldn't work. All of our code is C#, so i'm not sure how/if a COM+
app would work.

The MasterApp program will only communicate with an exe. MasterApp
writes its output to a directory, calls calc.exe with a couple of
command line parameters (location of its output, etc), then waits for
calc.exe to exit.

I hope i've answered your questions.

I great appreciate your response.
- Carl.

I would suggest in-proc remoting, that is, let the master application create
a separate Application Domain (AD) that handles the core business (so
you'll have to load the assemblies in that domain). The master application
can pass the XML as an argument in a (asynchronous) remoting call that
starts the business process, let the 'report' be the return 'value' of the
call, or use a call-back when done.

Willy.

[C_Bone]

Well, the problem with that is the MasterApp is a 3rd party application
over which I have no control. They will ONLY interact with my app in
the way in which I have described.

Thanks,
Carl

[C_Bone]

Well, the problem with that is the MasterApp is a 3rd party application
over which I have no control. They will ONLY interact with my app in
the way in which I have described.

Thanks,
Carl

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Well, the problem with that is the MasterApp is a 3rd party application
over which I have no control. They will ONLY interact with my app in
the way in which I have described.

Thanks,
Carl

Well, I'm afraid you're stuck, the master application starts a new calc.exe
for each report, so your calc.exe has to start all over again, there is
nothing that can be left in memory once a process has terminated.

Willy.

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Well, the problem with that is the MasterApp is a 3rd party application
over which I have no control. They will ONLY interact with my app in
the way in which I have described.

Thanks,
Carl

Well, I'm afraid you're stuck, the master application starts a new calc.exe
for each report, so your calc.exe has to start all over again, there is
nothing that can be left in memory once a process has terminated.

Willy.

[C_Bone]

Let's pretend for a second that I put *another* exe in between the two
apps... call it "CalcWrapper.exe".

If MasterApp.exe calls CalcWrapper (which in turn calls calc.exe),
would it then be possible to do what i'm thinking and have Calc.exe
stay running as described above?

[C_Bone]

Let's pretend for a second that I put *another* exe in between the two
apps... call it "CalcWrapper.exe".

If MasterApp.exe calls CalcWrapper (which in turn calls calc.exe),
would it then be possible to do what i'm thinking and have Calc.exe
stay running as described above?

[Reginald Blue]

C_Bone wrote:

Well, the problem with that is the MasterApp is a 3rd party
application over which I have no control. They will ONLY interact
with my app in the way in which I have described.

Thanks,
Carl

Is it possible to break your application into two pieces? One that the 3rd
party app calls, and one that actually runs the calculations? The one the
app calls would communicate to the other one via some protocol (TCP,
perhaps), and the other could stay running?

The only problem would be if the amount of data that's communicated between
the two is large.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]

[Reginald Blue]

C_Bone wrote:

Well, the problem with that is the MasterApp is a 3rd party
application over which I have no control. They will ONLY interact
with my app in the way in which I have described.

Thanks,
Carl

Is it possible to break your application into two pieces? One that the 3rd
party app calls, and one that actually runs the calculations? The one the
app calls would communicate to the other one via some protocol (TCP,
perhaps), and the other could stay running?

The only problem would be if the amount of data that's communicated between
the two is large.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]

[C_Bone]

Yes, it would be possible to do that.... the data sent between the two
wouldn't be very large.

So are you saying have them communicate via TCP when all of the
applications, etc. are on one machine?

[C_Bone]

Yes, it would be possible to do that.... the data sent between the two
wouldn't be very large.

So are you saying have them communicate via TCP when all of the
applications, etc. are on one machine?

[Michael S]

No, I think you would make matters worse.
As Willy has already told you, you're stuck.

What you are doing is not recommended. It's not 'Process Delegation' or
'PolyProcessing' or anything with a cool name; it's simply process-trashing
and Windows was not built for that kinda treatment. Sorry...

Happy Coding
- Michael S

"C_Bone" <ca******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Let's pretend for a second that I put *another* exe in between the two
apps... call it "CalcWrapper.exe".

If MasterApp.exe calls CalcWrapper (which in turn calls calc.exe),
would it then be possible to do what i'm thinking and have Calc.exe
stay running as described above?

[Michael S]

No, I think you would make matters worse.
As Willy has already told you, you're stuck.

What you are doing is not recommended. It's not 'Process Delegation' or
'PolyProcessing' or anything with a cool name; it's simply process-trashing
and Windows was not built for that kinda treatment. Sorry...

Happy Coding
- Michael S

"C_Bone" <ca******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Let's pretend for a second that I put *another* exe in between the two
apps... call it "CalcWrapper.exe".

If MasterApp.exe calls CalcWrapper (which in turn calls calc.exe),
would it then be possible to do what i'm thinking and have Calc.exe
stay running as described above?

[Mythran]

"C_Bone" <ca******@gmail.com> wrote in message
news:11********************@g47g2000cwa.googlegrou ps.com...

Yes, it would be possible to do that.... the data sent between the two
wouldn't be very large.

So are you saying have them communicate via TCP when all of the
applications, etc. are on one machine?

Have CalcWrapper.exe call a Windows Service?

Mythran

[Mythran]

"C_Bone" <ca******@gmail.com> wrote in message
news:11********************@g47g2000cwa.googlegrou ps.com...

Yes, it would be possible to do that.... the data sent between the two
wouldn't be very large.

So are you saying have them communicate via TCP when all of the
applications, etc. are on one machine?

Have CalcWrapper.exe call a Windows Service?

Mythran

[Reginald Blue]

C_Bone wrote:

Yes, it would be possible to do that.... the data sent between the two
wouldn't be very large.

So are you saying have them communicate via TCP when all of the
applications, etc. are on one machine?

Sure.

Though, TCP may not be the best choice. I would recommend it if you had
some experience with it, but if you don't have any particular knowledge of
TCP, you could be better served going with something else.

Perhaps remoting because of it's object oriented nature? Perhaps shared
memory because it would be very fast?

TCP is a good fallback though, as it allows you a bit of flexibility if you
need it for the future.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]

[Reginald Blue]

C_Bone wrote:

Yes, it would be possible to do that.... the data sent between the two
wouldn't be very large.

So are you saying have them communicate via TCP when all of the
applications, etc. are on one machine?

Sure.

Though, TCP may not be the best choice. I would recommend it if you had
some experience with it, but if you don't have any particular knowledge of
TCP, you could be better served going with something else.

Perhaps remoting because of it's object oriented nature? Perhaps shared
memory because it would be very fast?

TCP is a good fallback though, as it allows you a bit of flexibility if you
need it for the future.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Let's pretend for a second that I put *another* exe in between the two
apps... call it "CalcWrapper.exe".

If MasterApp.exe calls CalcWrapper (which in turn calls calc.exe),
would it then be possible to do what i'm thinking and have Calc.exe
stay running as described above?

Like Michael said, it probably will make things worse. The reason you want
to keep your business process alive is to eliminate the "start-up cost",
that makes me think that the actual "service time" is small and you think
the start-up time takes a considerable amount of the total processing time.
If that's the case you won't see any gain because now you will waste your
time by starting a middleman and by passing the XML stream to yet another
process.

Willy.

[Willy Denoyette [MVP]]

"C_Bone" <ca******@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Let's pretend for a second that I put *another* exe in between the two
apps... call it "CalcWrapper.exe".

If MasterApp.exe calls CalcWrapper (which in turn calls calc.exe),
would it then be possible to do what i'm thinking and have Calc.exe
stay running as described above?

Like Michael said, it probably will make things worse. The reason you want
to keep your business process alive is to eliminate the "start-up cost",
that makes me think that the actual "service time" is small and you think
the start-up time takes a considerable amount of the total processing time.
If that's the case you won't see any gain because now you will waste your
time by starting a middleman and by passing the XML stream to yet another
process.

Willy.

[C_Bone]

Willy, you nailed it as far as performance.

The start-up time of the app is a large percentage of the total time.
The service time is actually pretty fast.

[C_Bone]

Willy, you nailed it as far as performance.

The start-up time of the app is a large percentage of the total time.
The service time is actually pretty fast.

[Reginald Blue]

Michael S wrote:

No, I think you would make matters worse.
As Willy has already told you, you're stuck.

What you are doing is not recommended. It's not 'Process Delegation'
or 'PolyProcessing' or anything with a cool name; it's simply
process-trashing and Windows was not built for that kinda treatment.
Sorry...

I can't say that I agree with that. Although it is most unfortunate that
the Master program in his work expects things to operate in a Unix-like way
(start process, do work, terminate), adding a stable process "in the back
end" isn't going to cause the problem you suggest... he already has that
problem because of the way the Master program is working.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]

[Reginald Blue]

Michael S wrote:

No, I think you would make matters worse.
As Willy has already told you, you're stuck.

What you are doing is not recommended. It's not 'Process Delegation'
or 'PolyProcessing' or anything with a cool name; it's simply
process-trashing and Windows was not built for that kinda treatment.
Sorry...

I can't say that I agree with that. Although it is most unfortunate that
the Master program in his work expects things to operate in a Unix-like way
(start process, do work, terminate), adding a stable process "in the back
end" isn't going to cause the problem you suggest... he already has that
problem because of the way the Master program is working.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]