Logging requests of Zend Framework application - zend-framework

i need help with logging Zend Framewrok application ( version 1.11 ), every request..
I need to know time of beinning request and time of executing request. Each request i would like to save into database, but i'm not sure, where i would catch these informations.
Beggining of request i can probably catch in bootstrap.php via some _init method. But in which place should I cach information about end of execution request, if i need to be connected into database? In addition i'm using $this->_redirector->gotoSimpleAndExit() in my controllers and i need count with that case - no view is rendered and request is finished simply by exit() function.
I would like to write log information only once per request.
Thank's for help!

Registration of shut down function helped very well.
http://php.net/manual/en/function.register-shutdown-function.php
I created custom logger (singleton pattern), that i'm calling in bootstrap.. since php 5.4 is available $_SERVER['REQUEST_TIME_FLOAT']. Logger register his method as shutdown function in constructor and also call it in his destructor. Multiple calling of shutdown function is prevented.
This solution is working even if exit() function is called.

For one of my projects, I'm putting the "end of execution" logging code in my layout script. It's supposed to be one of the "last" things to be executed.
I'm not using redirections for this project, though. So, I'm not sure how it should be extended to consider your "gotoSimpleAndExit()" case.
Hope that helps,

Related

GWT: Client procedure and rpc request are always called several times with multiple thread id

For some client side procedures, I implement remote logging to log the calling of the procedure. The log is printed several times with different thread id, even though the procedure is only called once. Some rpc requests are sent to the sever a few times which causes some database session problem. Is it normal? Is there anyway to avoid it?
Thanks
This is not normal, and suggests there is a bug on your client causing it to send the same call more than once. Try adding logging on the client where you invoke the RPC call, and possibly add breakpoints to confirm why it is being called twice.
My best guess with no other information would be that you have more than one event handler wired up to the same button, or something like that.
--
More specifically, your servlet container starts multiple threads to handle incoming requests - if two requests come in close succession, they might be handled by different threads.
As you noted, this can cause problems with a database, where two simultaneous calls could be made to change the same data, especially if you have some checks to ensure that a servlet call cannot accidentally overwrite some newer data. This is almost certainly a bug in your client code, and debugging it should start there.

Global exception handling for REST calls in Ember-CLI

In my ember-cli app I use a token based approach to communicate with a secured REST interface on the server side. As tokens expire after some time, I would like to realize the following behaviour:
As soon as the client tries to access the REST service with an expired token, I would like the user to be redirected to the login screen.
Right now I use the 'catch' function on the store's find method while fetching data in the route's model callback. This works quite well. As a matter of fact, there are more REST invocations than the ones that refer to the model store.
What would be the best practice to deal with this situation? In what place should I implement the (exception) handling? As this seems to be a crosscutting concern, I'd like to implement it in a central place.
I prefer to follow an optimistic approach, thus not checking the validity of the token on each and every transition. It will be sufficient if the redirect will take place the moment the application tries to communicate with the REST interface (ie as soon as it gets the error message from the server).
Thanks
You may want to consider the global jquery hooks so you can respond to an Auth fail uniformly. See:
http://api.jquery.com/category/ajax/global-ajax-event-handlers/
It's up to you if you want to set window.location or lookup your application controller and use transitionToRoute() for switching to the login route. Make sure that if you use Ember functions to put your code in an Ember.run.once() from your jquery hook function so it occurs on the Ember run loop.
You could also consider using Ember SimpleAuth (which kind of locks you into its paradigm) or even better and a safer long term priposal IMO, doing it from scratch by first following these tutorials:
- http://coderberry.me/blog/2013/07/08/authentication-with-emberjs-part-1/
- http://coderberry.me/blog/2013/07/08/authentication-with-emberjs-part-2/
And then this which is newer and incorporates the above tutorials:
- http://webcloud.info/blog/2014/04/07/emberjs-authentication-the-right-way-javascript-version/

What is the difference between scheduleFinally and scheduleDeferred in GWT Scheduler?

I could not find my answer in this thread:
Using the GWT Scheduler
The GWT Scheduler class has scheduleDeferred API which executes after the browser event loop returns. The scheduleFinally API allows me to execute code before the control returns to the browser event loop.
How do I decide whether I should use scheduleDeferred or scheduleFinally? Is there a code example which shows the difference in behavior?
To understand this, you need to first get the basic idea of an event loop. When you write code to run in the browser, you don't write this loop - it lives in the browser, waiting for the user to do something. When that something happens (mouse event, keyboard event, AJAX call returns, setTimeout goes off), the loop calls into your code, and lets you handle it however you would like to.
So first, we have scheduleDeferred, which is a way to notify the browser that we have some code to run soon, but not in this loop. This is a handy way to let the browser regain control, render some content, and then give you control again. This can be helpful to break up calculations into several chunks to avoid any "long running script" errors, or can be an early attempt at animation (Note: use the actual requestAnimationFrame api from the browser, or AnimationScheduler.get().requestAnimationFrame in GWT instead for this).
Next, there are two interesting places in the loop where you might have code that you would like to run - either right as the browser transfers control to you, or right before you return control back again. Of these two, the end is usually more interesting: scheduleFinally. This lets you run some code inside the current event loop, but not until the very end of it. CssResource uses this strategy in its ensureInjected() method - when you run several different calls to this method, rather than poking the DOM several times, it batches them all up and runs them at the end of the event loop, using scheduleFinally.
The last one, the beginning of each event loop is managed by another method - scheduleEntry. In theory, this could be used in conjunction with finally to reimplement a simple version of AngularJS's binding wiring.
//event comes in to GWT from the $entry method, and follows these steps
try {
// 1. run registered scheduleEntry calls
// 2. run the current event or callback that the browser called us for
} finally {
// 3. run registered scheduleFinally calls
}
Any call to scheduleDeferred during those steps has added a call to the next event loop, to run as part of #2.

Why a form is needed for a SetWinEventHook callback?

Currently, I'm using the powerful SetWinEventHook() function to catch some user-interface's actions like minimizing and maximizing from other window runned by programs on the computer.
So I inspired myself by using the code provided by BrendanMcK on this post and it does work (I mean: the callback function is called when an event occurs) until the line
MessageBox.Show("Something")
is present. But I don't want to use any form or window for this program..
After some research, I figured out this kind of hook needs a message loop to allow the redirection of messages from other window handles. Apparently, calling the thread using Application.Run() should do the trick, but I would prefer something cleaner, in the C# object itself.
So my question is: is it possible to create a message loop inside an object's method?
http://bytes.com/topic/c-sharp/answers/557342-thread-message-loop-c
No, the function doesn't require a window handle so no "form" is needed. But the MSDN docs for the function is quite explicit:
The client thread that calls SetWinEventHook must have a message loop in order to receive events.
A message loop is universal in any program that want to receive notifications that are generated externally by other processes or threads. It is the common solution to the producer-consumer problem. Clearly any GUI app has a need for such a solution, Windows messages are generated by the operating system. It isn't different for SetWinEventHook(), the accessibility events originate in other programs. There is no clean mechanism to "interrupt" a thread and make it run other code, the re-entrancy problems that causes are extremely difficult to deal with. The thread has to co-operate, it must be idle and ready to receive a notification to safely process it. A message loop solves that problem.
Pumping a message loop (calling Application.Run) in a method is certainly possible. But do keep in mind that the method won't return until you explicitly stop the loop with Application.ExitThread. There is therefore usually only one good place for that call, the Main() method of your program.
Starting your project with a Winforms or WPF project template is a very good way to get this right. You have no need to actually create a window, call Application.Run() without an argument, after pinvoking SetWinEventHook.

How to use a WF DelayActivity in an ASP.Net web based workflow

I have a web application that I am adding workflow functionality to using Windows Workflow Foundation. I have based my solution around K. Scott Allen's Orders Workflow example on OdeToCode. At the start I didn't realise the significance of the caveat "if you use Delay activities with and configure active timers for the manual scheduling service, these events will happen on a background thread that is not associated with an HTTP request". I now need to use Delay activities and it doesn't work as is with his solution architecture. Has anyone come across this and found a good solution to this? The example is linked to from a lot of places but I haven't seen anyone else come across this issue and it seems like a bit of a show stopper to me.
Edit: The problem is that the results from the workflow are returned to the the web application via HttpContext. I am using the ManualWorkflowSchedulerService with the useActiveTimers and this works fine for most situations because workflow events are fired from the web app and HttpContext still exists when the workflow results are returned and the web app can continue processing. When a delay activity is used processing happens on a background thread and when it tries to return results to the web app, there is no valid HttpContext (because there has been no Http Request), so further processing fails. That is, the webapp is trying to process the workflow results but there has been no http request.
I think I need to do all post Delay activity processing within the workflow rather than handing off to the web app.
Cheers.
You didn't describe the problem you are having. But maybe this is of some help.
You can use the ManualWorkflowSchedulerService with the useActiveTimers and the workflow will continue on another thread. Normally this is fine because your HTTP request has already finished and it doesn't really matter.
If however you need full control the workflow runtime will let you get a handle on all loaded workflows using the GetLoadedWorkflows() function. This will return acollection of WorkflowInstance objects. usign these you can can call the GetWorkflowNextTimerExpiration() to check which is expired. If one is you can manually resume it. In this case you want to use the ManualWorkflowSchedulerService with the useActiveTimers=false so you can control the last thread as well. However in most cases using useActiveTimers=true works perfectly well.