In the last video we added in a second argument to the subscribe call to set up that Q Group.
Now it turns out that there are many other ways that we can customize a subscription only the first
two arguments that you see right here which is the name of the channel we want to listen for and the
Q Group Name are provided as simple strings all the other options that we're gonna provide to a subscribe
call are going to be all a bit more complex just setup.
Let me first show you how we can set some other options and we'll describe some of the different options
that we very frequently want to change right above the subscription itself.
I'm going to create a new variable called options and I'm going to get this from Stan dot subscription
options like so now for most libraries in the javascript world.
You would expect to set some options by maybe passing in an object to this or something like that.
Well that's not how it works with the node Nat streaming library.
Instead if we want to set any additional options on this thing we're gonna change them on as additional
method calls.
So there are other options we can set on here such as set deliver all available got a typo in their
available.
There's another option called set manual ACH mode.
There's other options such as set Max in flight.
So these are all different options we can set and to set them.
We're going to change them on to the subscription options call.
So in total we might decide to set several different options by doing something like set deliver all
available and then maybe something else like set durable name.
And so on.
So this is how we are going to eventually set options.
We train on a bunch of additional method calls right now.
I do not want to set any these options in particular.
I just want to give you a quick demonstration so I gonna delete those chained on statements after we
create that options object.
We will then provide it as the third argument to the subscribe call so we'll put an options right there.
Like so all right.
So that is how we generally set options.
But what are some options we actually care about.
Well let's now continue.
We're gonna take a look at a diagram.
I'm gonna show you one option that we're going to set for almost every subscription we create.
So let's go back to our scenario where we have two separate copies of the order service.
Let's imagine that the order service has set up a Q Group and then maybe our publisher publishes some
events to this channel so as we just discussed Natsumi server is going to take this event it's going
to look at all the members of the Q Group and decide to send the events off to just one of these services.
So maybe in this case the event is sent off to the first copy of the order service so it's going to
flow into this subscription and then maybe inside there we decide to do some processing on that event
and save some information to a database or something like that.
Now let's further imagine for just a moment that as we go and try to save some data to that database
we fail entirely maybe we temporary temporarily lose our connection to the database maybe the database
is down for some kind of upgrading or something like that or maybe the information we're trying to save
is just plain invalid and the database rejects the insertion or the save request.
So whatever it is let's imagine that as we try to save data we failed with some kind of error now.
Unfortunately the default behavior we can't change this.
And that's what we're gonna use that options object for the default behavior is to say that any time
an event is received by a subscription it is automatically marked as hey we receive the event.
This thing has been processed.
Everything is good to go.
So the default behavior is if we end up with any kind of air inside of our subscription when we receive
that event the event is essentially lost.
And we do not get some follow up opportunity to process it again or something like that.
Now I wanna repeat for a third time this is the default behavior and we can't change it and we definitely
want to.
The reason we would want to change this default behavior is that maybe there's some really really critical
information inside this event.
For example maybe this event has some information about a payment that a user just made and we need
to make sure that the order service knows that a payment was just created so that we can actually ship
them some goods or something like that.
So we really need to make sure that every single time we receive an event if we end up with any kind
of error we have to somehow figure out how we can reprocess this event or attempt to process it a second
time so to do so.
Like I said we're gonna add an option to this options object in particular we're going to add in an
option called set manual hack mode and we're gonna pass in true like so so what is this option do.
Well as you can kind of guess from the name it sets the manual ak ak is short for acknowledgement mode
to true.
Like I said the default behavior with all of our subscriptions is that as soon as we receive the event
the know that streaming library is going to turn back around to the Net server and say hey we received
the event.
Everything is good to go.
But if we rely upon that default behavior if anything goes incorrectly inside of our message handler
right here then that's it.
We're never gonna hear about this event again.
By setting it manual act mode to true the no not streaming library is no longer going to automatically
acknowledge or tell the Natsumi library that we have received the event and instead it will be up to
you and I to run some processing on that event possibly save some information to the database.
And then after that entire process is complete only after Will we then acknowledge the message and say
OK everything has been processed successfully if we do not acknowledge the incoming event then the Napster
server is going to wait some amount of time.
I believe it's 30 seconds by default.
Then after 30 seconds of not getting an acknowledgement it's going to automatically decide to take that
event and send it on to some other member of that Q Group or possibly if there's not a part of a Q Group
just send it back to the same service again and allow it to give it to have another shot at processing
this thing so let's add on manual act mode of true and then go in to save this file and we're going
to see what happens if we do not add in any code to acknowledge that incoming event is gonna go back
over to my terminal.
Looks like they've both restarted.
They should now be in manual act mode so I'm not going to send another event by doing an R S over here.
So we'll see over here that now the second listener for me has received the event but I am not going
to acknowledge it so right now Nat string server is pretty much just sitting there saying OK I sent
them the event but I haven't heard back yet.
Gee I sure hope everything is going OK and is just sitting twiddling its thumbs waiting to get an acknowledgement
for the event.
But we are not sending it because we are in Matt manual act mode.
You and I have to add in some code to manually say hey we received this event and then after about 30
seconds looks like 30 seconds just past that streaming server eventually gives up and says OK I don't
think they process this event successfully.
I'm just gonna go ahead and send it to another copy or another member of the SKU group or possibly the
same service.
If this thing is not a member of a queue group and so that's why after 30 seconds we saw event number
fifty nine which is the same one up here up here.
Now even for this first copy of the listener we are not going to acknowledge this message either.
So after another 30 seconds Nat streaming server is going to say OK they failed as well.
I'm going to try back with this original person down here so it's going to send off event fifty nine
back to this first one again and again we're not going to acknowledge it.
NATS is gonna wait another 30 seconds and I think you get the idea so we can fix this if we go back
over to our subscription handler right here and then at some point in time inside of here we have to
call MSP dot ACH and that's pretty much it so EC is gonna tell the node Nats streaming library to reach
back out to the Nats streaming server and tell it hey we received the message and it has been processed.
So if we now save this flip makeover we are still processing event number fifty nine.
So that message is still out there in the wild.
Natsumi server is still trying to successfully deliver it to our Q Group.
It's now at some point in time we should see that message appear.
After about 30 seconds or so inside of these two windows one of these two.
And there it is right there.
So now we receive fifty nine for like the fifth time or so.
And as soon as we received it we have now acknowledged that incoming events and since we have acknowledged
it now Natsumi server says Okay it's been delivered.
I'm done.
I don't have to worry about event 59 anymore.
Now quick note if you do not see after restarting the thing if you do not see another console log right
here of event fifty nine or whatever number it is for you.
That is OK.
So as soon as you added in this message shot at right here and then save the file.
If you did not see any further console logs.
Even if you dispatch another event that is totally fine.
I'm going to show you why that is and just a little bit all right.
So in total that is our option of set manual at mode.
We put that in to make sure that we can successfully complete processing and if we do not complete processing.
Maybe there's some air inside of here.
We will not act the message and that means that Nat streaming server is going to try to read delivered
that message again so we get another opportunity to process it.
I apologize for this really long video but as you can guess this manual act mode to true is an extremely
important setting because it's going to make sure that we always get the opportunity to process data
even if something goes wrong in processing it in some earlier attempt.
So let's pause right here and continue in just a moment.