As in the tutorial "MVC + Events + Modules: the new architecture of ZF2" by Enrico Zimuel shown, the basic ZF2 MVC events structure looks like this:
ZF MVC Auth extends the adds the basic MVC flow, adding four events to it (EVENT_AUTHENTICATION, EVENT_AUTHENTICATION_POST, EVENT_AUTHORIZATION, EVENT_AUTHORIZATION_POST).
Now I'm reading the Apigility "Advanced Authentication and Authorization" documentation, that says:
In order to achieve integration to the ZF2 MVC lifecycle for authentication, zf-mvc-auth wires in 4 listeners that then propagate their own events. Each of these listeners are registered within the event MvcEvent::EVENT_ROUTE at different priorities.
Two point are unclear for me:
"Each of these listeners are registered within the event MvcEvent::EVENT_ROUTE" -- "Nested events"? What does this mean?
"within the event MvcEvent::EVENT_ROUTE at different priorities" -- Is the events priorities hierarchy "nested" / not straight-line? Is it multidimensional?
You would attach listeners to or on events; these listeners would be ordered by their priority.
When the event is triggered (say event MvcEvent::EVENT_ROUTE) the listeners that are registered would execute one-by-one, starting with the listener with the highest priority through to the lowest.
"Nested events" or "propagate their own events" would be where one of these listeners triggers another event. An example of this is the listener for rendering, \Zend\View\Http\DefaultRenderingStrategy::render(), where MvcEvent::EVENT_RENDER_ERROR is triggered when a rendering error occurs.
Related
I want to implement a Axon projection providing a subscription query. The projection persists entities of a specific based on the events (CRUD). The following should happen if a replay of the projection is executed:
Inform about a empty collection via the subscription query.
Process the events until the projection catches up with the event store.
Inform about the current state of the entities via the subscription query.
My intention is that the subscription query should not inform about many events in a very short time and I want to prevent informing about many intermediate positions (e.g. create and delete a specific entity, it should not be used in the subscription query, because it is not available after catching up).
Currently I cannot implement the third step, because I miss a hook for reacting to the moment when the Axon projection is catching up again.
I use Axon v4.5 and Spring Boot v2.4.5.
At the moment, the Reference Guide is sadly not extremely specific on how to achieve this. I can assure you though that work is underway to improve the entire Event Processor section, including a clearer explanation of the Replay process and the hooks you have.
However, the possible hooks are stated as it is (you can find them here).
What you can do to know whether your event handlers are replaying yes/no, is to utilize the ReplayStatus enumeration. This enum can be used as an additional parameter to your #EventHandler annotated method, holding just two states:
REPLAY
REGULAR
This enumeration allows for conditional logic within an event handler on what to do during replays. If an event handler for example not only updates a projection but also sends an email, you'd want to make sure the email isn't sent again when replaying.
To further clarify how to use this, consider the following snippet:
#EventHandler
public void on(SomeEvent event, ReplayStatus replayStatus) {
if (replayStatus == REGULAR) {
// perform tasks that only may happen when the processor is not replaying
}
// perform tasks that can happen during regular processing and replaying
}
It's within the if-block where you could invoke the QueryUpdateEmitter, to only emit updates when the event handler is performing the regular event handling process.
I'm dealing with Spring Integration Events and need to ensure proper order of event calls. I have two listeners. One is called TerminalErrorListener and catches TcpConnectionExceptionEvent and TcpDeserializationExceptionEvent. Second is called TerminalDisconnectEventListener and catches TcpConnectionCloseEvent.
In my case I use NIO and manually extended TcpNioConnection with my class which contains one extra field. This field is called Originator and carries information about what caused TcpConnectionCloseEvent and here comes my question.
I define the originator inside TerminalErrorListener and need to ensure that TerminalDisconnectEventListener is called after the TerminalErrorListener.
How can I generally ensure (probably I can guarantee that close event is called after the error) that this will happen? Is there any priority mode or default flow model which can be seen in some kind of diagram? I mean when are specific events called and what is the general sequence of all events.
Thanks for answer.
With NIO, there is no guarantee that you will get the deserialization failure event before the connection close event.
I'm trying to wrap my head around Laravel's queued event listener vs jobs.
To me, it seems like that both are very similar:
Both implement the ShouldQueue interface (in the case of event listener, this is an option)
Both implement the handle() and failed() (optional) methods to perform their respective tasks.
Essentially, to me, both are queued items that can be run asynchronously.
What I am able to distinguish so far is that jobs have more "advanced" features/configurations like $timeout, $tries properties and you may also delay the 'trigger' of a job (courtesy of the Illuminate\Bus\Queueable trait).
There are more I'm sure, but I'm pointing out the one that pops out to me.
So, the question is, what's the actual difference between the two and more importantly, when do you favor one over the other?
Good question, I will begin by how laravel docs explains it
Events : Laravel's events provides a simple observer implementation, allowing you to subscribe and listen for various events that occur in your application. Events serve as a great way to decouple various aspects of your application, since a single event can have multiple listeners that do not depend on each other.
Where as
Jobs : Job classes are very simple, normally containing only a handle method which is called when the job is processed by the queue.
Essentially both are pushing jobs on to queues and/or do some processing its asked to do, the main difference I would say is how they are called.
Events are on the lookout to be called where as Jobs are always explicitly called.
Power of Events is that we can register multiple listeners for a single event and the event helper will dispatch the event to all of its registered listeners without us calling them explicitly. where in case of Jobs we would have to call them each one explicitly.
In short if you have a scenario where an event would trigger multiple method calls event would help. If its a single method call Jobs are good.
Events Scenario: user signs up -> Send email, Dispatch complimentary swag, Create a subdomain for a user profile userxyz.site.com etc etc
Jobs Scenario: user signs up -> Send email.
In the exact context of the question: "Event" is a "Queued Event Listener". Every Laravel Event has a Listener bound to it (the event listener), then, when we queue that event (in the listener) it is magically a "Queued Event Listener"
Well, they are very similar, the eventlistener takes an event as a parameter in the handle method, jobs don't.
Events are good in situations where you want to decouple the triggering part from the action part. For instance when you have several modules in the project and you want one module to react on an event in another.
One limitation of events compared to jobs are job chaining. If you for instance trigger several events from a controller you can't be sure that the worker dispatches them in sequence and that the first is completed before the other is started.
In these (rare) situations I sometimes end up with (non queued) listeners that in turn dispatches (queued) jobs that do the actual work (chained or unchained).
I'm working in the Symfony2 framework and wondering when would one use a Doctrine subscriber versus a listener. Doctrine's documentation for listeners is very clear, however subscribers are rather glossed over. Symfony's cookbook entry is similar.
From my point of view, there is only one major difference:
The Listener is signed up specifying the events on which it listens.
The Subscriber has a method telling the dispatcher what events it is listening to
This might not seem like a big difference, but if you think about it, there are some cases when you want to use one over the other:
You can assign one listener to many dispatchers with different events, as they are set at registration time. You only need to make sure every method is in place in the listener
You can change the events a subscriber is registered for at runtime and even after registering the subscriber by changing the return value of getSubscribedEvents (Think about a time where you listen to a very noisy event and you only want to execute something one time)
There might be other differences I'm not aware of though!
Don't know whether it is done accidentally or intentionally.. But subscribers have higher priority that listeners - https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php#L73-L98
From doctrine side, it doesn't care what it is (listener or subscriber), eventually both are registered as listeners - https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/EventManager.php#L137-L140
This is what I spotted.
You should use event subscriber when you want to deal with multiple events in one class, for example in this symfony2 doc page article, one may notice that event listener can only manage one event, but lets say you want to deal with several events for one entity, prePersist, preUpdate, postPersist etc... if you use event listener you would have to code several event listener, one for each event, but if you go with event subscriber you just have to code one class the event susbcriber, look that with the event subscriber you can manage more than one event in one class, well thats the way i use it, i preffer to code focused in what the model business need, one example of this may be went you want to handle several lifecycle events globaly only for a group of your entities, to do that you can code a parent class and defined those global methods in it, then make your entities inherit that class and later in your event susbcriber you subscribe every event you want, prePersist, preUpdate, postPersist etc... and then ask for that parent class and execute those global methods.
Another important thing: Doctrine EventSubscribers do not allow you to set a priority.
Read more on this issue here
Both allow you to execute something on a particular event pre / post persist etc.
However listeners only allow you to execute behaviours encapsulated within your Entity. So an example might be updating a "date_edited" timestamp.
If you need to move outside the context of your Entity, then you'll need a subscriber. A good example might be for calling an external API, or if you need to use / inspect data not directly related to your Entity.
Here is what the doc is saying about that in 4.1.
As this is globally applied to events, I suppose it's also valid for Doctrine (not 100% sure).
Listeners or Subscribers
Listeners and subscribers can be used in the same application indistinctly. The decision to use either of them is usually a matter
of personal taste. However, there are some minor advantages for each
of them:
Subscribers are easier to reuse because the knowledge of the events is kept in the class rather than in the service definition.
This is
the reason why Symfony uses subscribers internally;
Listeners are more flexible because bundles can enable or disable each of them conditionally depending on some configuration value.
http://symfony.com/doc/master/event_dispatcher.html#listeners-or-subscribers
From the documentation :
The most common way to listen to an event is to register an event
listener with the dispatcher. This listener can listen to one or more
events and is notified each time those events are dispatched.
Another way to listen to events is via an event subscriber. An event
subscriber is a PHP class that's able to tell the dispatcher exactly
which events it should subscribe to. It implements the
EventSubscriberInterface interface, which requires a single static
method called getSubscribedEvents().
See the example here :
https://symfony.com/doc/3.3/components/event_dispatcher.html
I am building an application which acts as an event listener and based on the events received it needs to execute certain steps or work-flow. Is it better to have events posted to a single queue and MDB invoking different business logic components based on event type or to have one queue per event type and the corresponding MDBs invoke different business logic ?
Our assumption is that a heavy workflow corresponding to a particular event will not affect the performance of other events since they are processed in separate queues.
Jms has a specific type of operation to support this use-case - message selectors.
Briefly, the business-logic message type would be set as a property of the message, and you would use a selector to filter them on a per-consumer basis.
The JMS spec assumes that the JMS implementation will perform optimizations to make these operations efficient, so that it should scale very well. This is the sort of tech that banking transactions are built on.