by Andrew Johnstone
Whilst using the Zend Platform on a clustered server enviroment, I came across a number of limitations, however many of these have now been resolved with the beta release of the Zend Platform named Buran.
I am excited to hear that the following features are/have been implemented in the Zend Platform.
“Just to give you some history – as we were the first to bring out profiling for PHP (which doesn’t require any setting of flags in code) we have been working on other features until people started using it more. You’ll probably be astounded to know that many people don’t use profiling and don’t even know what it is….
Anyway, this is this second such request we’ve had in a week for improvements to the profiler so it’s now been moved up the priority list, I’m not sure whether it will be part of Zend Platform or part of Zend Studio, but I’ll collect some more details from you on Monday and we’ll take it from there.”
Please shout and scream to make this a priority!
Heres some API information that I have been sent, which is currently not live at present…
API instructions
you can find these in the future in http://int.zend.com/wiki monitor_custom_event
void monitor_custom_event(string $class, string $text[, integer $severe, mixed $user_data])
Description:
* Public Yes
* Product Version - Buran
* Return Values
* Parameters
register_event_handler
boolean register_event_handler($event_handler_func
[[,$handler_register_name],$event_type_mask])* Description: Allow you to register a user function as an event handler.When a monitor event is triggerd all the user event handler are called and the return value from the handler is saved in an array keyed by the name the event handler was registered under. The event handlers results array is saved in the event_extra_data table.
* Public: Yes
* Product Version: Buran
* Return Value: TRUE on sucess and FALSE if an error occurs.
* Parameters: The first argument is a callback function that will be call when the event is triggered, object methods may also be invoked statically using this function by passing array($objectname, $methodname) to the function parameter. The second (optional) argument is name this function is registered under - if none is supplied, the function will be registerd under it's own name. The third (optional) parameter is a mask of event types that the handler should be called on by default it's set to MONITOR_EVENT_ALL.
unregister_event_handler
boolean unregister_event_handler(string handler_name)* Description: Allow you to unregister an event handler.
* Public: Yes
* Product Version - Buran
* Return Value: TRUE on sucess and FALSE if no handler we registered under the given name.
* Parameters: string handler_name - the name you registered with the handler you now wish to unregister.
XML Report Sample…
<?xml version="1.0" ?>
<event type event_id timestamp time severity>
<error type>error text</error>
<stats triggered_value avg load_average/>
<source file line/>
<script name host uri>
<vardata type name value/>
</script>
<function name>
<args>
<arg num value/>
</args>
</function>
<included_files>
<file name>
</included_files>
<backtrace>
<call depth function file line/>
</backtrace>
</event>
Andrew Johnstone is a software engineer / lead developer working at Everlution Software.
Development, Analysis And Research » Blog Archive » Zends Session Clustering 2.1.0Beta
August 28th, 2005 at 9:43 am
[...] of Zends Session Clustering that their marketing team had mentioned was due for a release (I assume this to have been delayed). Whilst I have been using standard file based s [...]
Zends Session Clustering 2.1.0Beta | Development, Analysis And Research
May 29th, 2010 at 12:27 pm
[...] release of Zends Session Clustering that their marketing team had mentioned was due for a release (I assume this to have been delayed). Whilst I have been using standard file based session’s for an on going project, I hit an [...]