Jump to content

Continuing execution even after error


hadoob024

Recommended Posts

I have this one issue.  While logging in into our system, we call a routine called getToken().  This calls a routine on another server (used to be able to securely access documents).  The issue we have is if that other server goes down, this call fails, and the user isn't able to login.  I want to make it so that even if the other server goes down, users can still login and access our system (just not documents). 

 

I know that I can't prevent fatal errors or even ignore them, correct (even with set_error_handler)?

 

Any thoughts?  It's a simple call, here's all it is:

 

require_once('include/utils.php');
$token=getToken();

Link to comment
Share on other sites

is the issue with the "require_once" statement?  If so then just change that to "include"

 

In the "include" file can you possibly first "ping" this other server to verify it is up?  If so then you could do..

If server_up then show documents and everything

else

show everything BUT documents.

 

Make sense?

Link to comment
Share on other sites

I rarely suggest using an error suppressor, but in this case this it seems appropriate since you'll be handling any errors in the code. Using this logic should make it do what you want it to do.

 

if( @include_once 'include/utils.php' ) {
     $token=getToken();
} else {
     // code to only allow user to access certain areas.
     // could also add a trigger_error() if you want to keep tabs on inclusion failures
}

Link to comment
Share on other sites

Interesting.  Yeah, I know it's not the require_once() that's failing because it's done locally.  It's the getToken() function that actually makes the call to our Document server.  The Document server then sends a unique token back. We then build the links to our documents using this token. The issue is that if that Document server goes down, we never get that token sent back. And this getToken() routine is called at the end of our logging in process, so if this routine gets hung up because the Document server went down, the login process never completes.

 

Does that make it more clear? What I want to do is make it so that if the Document server goes down, and the getToken() function fails, I want the script execution to continue. This will allow the user to continue to operate in the website (minus access to the documents).

 

Two follow-ups, the error suppressor doesn't work against FATAL errors, does it?

 

Also, I don't think we're allowed to PING that server.  Any other thoughts?

 

Thanks!

Link to comment
Share on other sites

If that's the case, why not just have the function return FALSE on failure, then if FALSE, limit what the user can do? There certainly has to be a way to work that out, I'd think.

 

I'm not allowed to modify the function getToken().  :shrug:

 

I can only modify that block of code from above:

	require_once('include/utils.php');
	$token=getToken();

Link to comment
Share on other sites

Well if you can't edit the getToken function, you'll just have to create a custom token for when it is unavailable... and code around that custom value throughout your script.

 

Example

@require_once('include/utils.php');
if(!function_exists('getToken'))  $token = "NOTOKEN";
else $token = getToken();




if($token == "NOTOKEN") {
     // Do or don't do something.
}

Link to comment
Share on other sites

I was thinking about something like that, but realized that it's not the require_once() function I'm worried about.  It's the execution of the getToken() function that causes the issue.  Like if I did something like:

 

$token=@getToken();

 

If the Document server is down, and getToken() is making a SOAP call to this server, will that result in a FATAL error?  If so, will adding the error suppressor let the code continue running?

Link to comment
Share on other sites

Quite simply, if you cannot modify getToken() or affect how it works, and it throws E_ERROR errors when it fails, then there is nothing you can do.

 

Your options would be like:

a) Alter the machine's hosts file to point whatever domain name SOAP uses to point back to your own server, then write custom code that attempts the same SOAP request to the real server

b) Get the PHP source code, make appropriate changes (eg, SOAP doesn't E_ERROR on error), and recompile

c) Use runkit to route calls to whatever functions are failing towards your own, custom functions

None of those are good.

Link to comment
Share on other sites

I don't understand why you can't just ping the remote server first to see if it is up.  IF so then get token.  If not then allow the user to be able to see the limited section you mentioned.

 

That or use php Curl to first open any page on said remote server to see if it is up.  IF so then get token.  If not then allow the user to be able to see the limited section you mentioned.

 

Also, I have to say this too:  If the remote server is going down that often that it is messing up your code than maybe your code is not the problem here but rather this remote server.

Link to comment
Share on other sites

Not sure, but I know that you can't ping the server.  It won't send back a response.

 

Yeah, I think I found something here that might work:

http://www.darqbyte.com/2009/10/21/timing-out-php-soap-calls/

 

Yup.  I think mgmt realized this too and are working to change the way these servers are setup.  They just wanted a band-aid fix in the meantime.  I'm wondering if it's even worth the time to implement the solution from above if this is going to change anyway.

Link to comment
Share on other sites

Ok, so ping requests are blocked.  IF there is ANY files on said remote server even a hello.txt file with that simply contains the word "hello" on the page.. you could use php curl to or fopen to open said remote file.  IF the file can be opened and the word hello read in then you know the server is up and running.  If not then said server is down.  Let me know what you come up with.

Link to comment
Share on other sites

I think mgmt just decided to change the way we're doing it.  Instead of requesting a token from the Document server, we're going to generate a token (during the login process) and then send that to the Document server.  If the server's down, then the login process can still continue and users can use the system (minus being able to access documents).  But since we're not asking for a token but generating it and sending it ourselves, we won't have this issue in the future.  I was in charge of a band-aid fix prior to this change going in (sometime this weekend).  Hopefully it works <wishful thinking>

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.