Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How to cancel running functions or close connection 1

Status
Not open for further replies.

Xaqte

IS-IT--Management
Oct 4, 2002
971
US
I currently have this setup:

ScriptA: sends request to ScriptB to create PDF report
ScriptB: creates the PDF report based on the request received from ScriptA

Sometimes reports take a little bit & the user that requested the PDF gets impatient and wants to cancel the request.

I need to offer the user a cancel button & I don't wan't to refresh the page.

Is there a way to quit the running script this way?

I've looked at:
register_shutdown_function

But that doesn't appear to do what I have described above.

Any thoughts/experiences are greatly appreciated!

X
 
I do not believe there is away to achieve what your trying to do through straight PHP (maybe some AJAX w/PHP).

When a PHP script is being executed the browser has already sent the request to the web server, and is waiting for a response. That response could be to reload the page, but it would then be a refresh.

You can use exit to kill PHP, but again when it exits it will cause the browser to load a page.

Why do you not what to reload the page? There maybe a work around...
 
What you might want to do is have one script be interactive with the user while the other actually processes the users request. This way, you can kill the script creating the PDF if the user decides to cancel.

---------------------------------------
 
thenewa2x,
That sounds exactly what I need! How would you propose doing this?

Itshim,
Why do you not what to reload the page?

This is at the client's request. I'm sure you know how this goes!

Thanks again,

X
 
an idea: instead of serving the pdf to the user via the browser why not send it by email. that way the user process does not need to attend the pdf generation.

generally if you want to achieve your goal i would suggest a flow that works like this:

1. page on which user requests the report
2. php processes request and hands over to a new page that displays a waiting message to the user and spawns a separate process to generate the pdf in the filesystem.
3. the waiting page has some javascript that uses ajax to query the server every n seconds to test whether the pdf has been created in the filesystem. if the result is true then use ajax to retrieve the pdf to the browser. you can easily put a cancel button onto the page to stop the periodic checking. this won't stop the server process and you should put a cronjob in place to empty the pdf dcirectory periodically (unless you need to keep them for audit trail/cacheing purposes).

one warning - i know that i have written code before to spawn a separate process and do something "in the background" but i can't for the life of me remember how i did it. i do recall that different web servers react differently to this kind of thing tho. i THINK that the way i did this was to write the things i wanted to do into a text file and then have a cron job run every 30 seconds to examine the text file and do the necessary.

hth
Justin
 
jpadie,
I like your three step idea... Could I do this only using PHP:

1. page on which user requests the report
2. php processes request and hands over to a new page that displays a waiting message to the user and spawns a separate process to generate the pdf in the filesystem.
3. when user wants to cancel, they send a request to the process that spawned the seperate process & it then cancels the seperate process that generates the pdf

How could I achieve step 3 with PHP?

Thanks again,
X
 
hmm .. kind of. you could use just php but it's not optimal. it would be better to combine with javascript.

if you did use just php you would have to have the please wait screen refreshing every few seconds. this should be a technical refresh though - it should not be too noticeable to the user. if you could use javascript as well that would be closer to optimal.

i have to say this is a wee bit over the top though! it's the kind of solution one sees on airline flight finder sites where the database queries are lengthy. how long do your pdf's take to generate?
 
hmm .. kind of. you could use just php but it's not optimal. it would be better to combine with javascript.

I agree, but I have to support users that do not have javascript enabled.

how long do your pdf's take to generate?

This is really varies... Some users only have enough data to create a 300+ page report, while other users have enough data to create a 2500+ page report. At most, it can take 5 - 7 minutes to create a report. And we all know how impatient some users can be.
 
3. when user wants to cancel, they send a request to the process that spawned the seperate process & it then cancels the seperate process that generates the pdf

are you using unix? if so you might be able to get the processid and kill it.

my solution was to cancel the process from the point of view of the user - ie that the browser no longer waits for the download. the server side process continues until it terminates or is timedout. this has an impact on server-load but sorts the user problem out!

but ... i've done a wee bit of research for you. if you are using windows there is a neat solution to all your problems written by those nice chaps at Zend. Check out their link:
 
a few more thoughts: the cancel button at the browser end - this MUST somehow communicate with the server either through ajax or flash or with a page refresh. if it is mandatory that not even a tiny page refresh is needed then you are left with flash/ajax. there is still a user dependency on having the client installed with falsh and/or enabling javascript.

there is no way that i can see of having the server-side process terminate through a user button-push without some form of client-server interaction.
 
are you using unix? if so you might be able to get the processid and kill it.

My server is a macintosh. And I don't see any new PIDs when generating the report.

a few more thoughts: the cancel button at the browser end - this MUST somehow communicate with the server either through ajax or flash or with a page refresh. if it is mandatory that not even a tiny page refresh is needed then you are left with flash/ajax.

Ok, I'm beginning to agree with you about refreshing... However, this still leaves the problem on how to terminate the script or function while it is running.
 
(i don't use mac but i'm pretty sure it's just a linux implementation?)

so ... two issues :

1. force the element of the script that generates the pdf file to work in the background so as not to delay user interaction;
2. find some way to cause the background script to terminate on forced cancellation by user.

possible approach:
1. you can do this a number of ways - exec or system might do the trick (with output directed to a file). however this does not give you enough control over the process. so consider instead proc_open. once the process is underway, use a while loop to test the value of a text file on the server.

2. to terminate the process use proc_terminate.

in the browser that is waiting for the output you must refresh the page every now and then to test for presence of the file that the user wants. you might consider doing this within a 1x1px iframe so as not to refresh the whole browser too much.

for the cancel button, when it is clicked have the server create a wee text file. the loop within 1 tests for the presence of the text file. if it finds it, it calls proc_terminate and deletes the text file. server process is killed and the user has already navigated from the waiting page so the client element is dead too.


 
jpadie,
I just looked up proc_open in the manual... It just might do the trick!

I'll try it out and report back with the results! Thanks!
 
while your there have a look at the process control functions too. they appear even more granular than proc_open and the granularity may be what you need (although i'd tell my client to sod off and send the files by email or drop them in a shared drive and send a confirm email or something).

good luck.
 
while your there have a look at the process control functions too.

Can you be more specific? I searched and couldn't find anything relating to process control...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top