1
00:00:01,920 --> 00:00:06,960
In the last video we added in a second argument to the subscribe call to set up that Q Group.

2
00:00:06,960 --> 00:00:11,730
Now it turns out that there are many other ways that we can customize a subscription only the first

3
00:00:11,730 --> 00:00:16,140
two arguments that you see right here which is the name of the channel we want to listen for and the

4
00:00:16,140 --> 00:00:21,600
Q Group Name are provided as simple strings all the other options that we're gonna provide to a subscribe

5
00:00:21,600 --> 00:00:24,540
call are going to be all a bit more complex just setup.

6
00:00:24,540 --> 00:00:28,620
Let me first show you how we can set some other options and we'll describe some of the different options

7
00:00:28,620 --> 00:00:32,570
that we very frequently want to change right above the subscription itself.

8
00:00:32,580 --> 00:00:38,580
I'm going to create a new variable called options and I'm going to get this from Stan dot subscription

9
00:00:38,940 --> 00:00:44,330
options like so now for most libraries in the javascript world.

10
00:00:44,430 --> 00:00:50,720
You would expect to set some options by maybe passing in an object to this or something like that.

11
00:00:50,730 --> 00:00:54,150
Well that's not how it works with the node Nat streaming library.

12
00:00:54,150 --> 00:00:59,190
Instead if we want to set any additional options on this thing we're gonna change them on as additional

13
00:00:59,190 --> 00:01:00,430
method calls.

14
00:01:00,450 --> 00:01:09,010
So there are other options we can set on here such as set deliver all available got a typo in their

15
00:01:09,250 --> 00:01:10,800
available.

16
00:01:10,850 --> 00:01:15,090
There's another option called set manual ACH mode.

17
00:01:15,170 --> 00:01:18,950
There's other options such as set Max in flight.

18
00:01:19,030 --> 00:01:21,730
So these are all different options we can set and to set them.

19
00:01:21,730 --> 00:01:24,940
We're going to change them on to the subscription options call.

20
00:01:24,940 --> 00:01:30,820
So in total we might decide to set several different options by doing something like set deliver all

21
00:01:30,940 --> 00:01:39,020
available and then maybe something else like set durable name.

22
00:01:39,070 --> 00:01:40,120
And so on.

23
00:01:40,120 --> 00:01:42,190
So this is how we are going to eventually set options.

24
00:01:42,190 --> 00:01:45,250
We train on a bunch of additional method calls right now.

25
00:01:45,250 --> 00:01:47,700
I do not want to set any these options in particular.

26
00:01:47,800 --> 00:01:52,640
I just want to give you a quick demonstration so I gonna delete those chained on statements after we

27
00:01:52,640 --> 00:01:54,030
create that options object.

28
00:01:54,050 --> 00:01:59,300
We will then provide it as the third argument to the subscribe call so we'll put an options right there.

29
00:01:59,300 --> 00:02:01,360
Like so all right.

30
00:02:01,370 --> 00:02:03,440
So that is how we generally set options.

31
00:02:03,530 --> 00:02:06,110
But what are some options we actually care about.

32
00:02:06,110 --> 00:02:07,150
Well let's now continue.

33
00:02:07,160 --> 00:02:08,370
We're gonna take a look at a diagram.

34
00:02:08,390 --> 00:02:13,530
I'm gonna show you one option that we're going to set for almost every subscription we create.

35
00:02:13,730 --> 00:02:19,520
So let's go back to our scenario where we have two separate copies of the order service.

36
00:02:19,520 --> 00:02:24,890
Let's imagine that the order service has set up a Q Group and then maybe our publisher publishes some

37
00:02:24,890 --> 00:02:31,000
events to this channel so as we just discussed Natsumi server is going to take this event it's going

38
00:02:31,000 --> 00:02:36,390
to look at all the members of the Q Group and decide to send the events off to just one of these services.

39
00:02:36,450 --> 00:02:41,710
So maybe in this case the event is sent off to the first copy of the order service so it's going to

40
00:02:41,710 --> 00:02:46,690
flow into this subscription and then maybe inside there we decide to do some processing on that event

41
00:02:47,020 --> 00:02:50,590
and save some information to a database or something like that.

42
00:02:50,600 --> 00:02:56,110
Now let's further imagine for just a moment that as we go and try to save some data to that database

43
00:02:56,950 --> 00:03:03,580
we fail entirely maybe we temporary temporarily lose our connection to the database maybe the database

44
00:03:03,610 --> 00:03:08,050
is down for some kind of upgrading or something like that or maybe the information we're trying to save

45
00:03:08,080 --> 00:03:13,010
is just plain invalid and the database rejects the insertion or the save request.

46
00:03:13,360 --> 00:03:20,740
So whatever it is let's imagine that as we try to save data we failed with some kind of error now.

47
00:03:20,750 --> 00:03:24,130
Unfortunately the default behavior we can't change this.

48
00:03:24,140 --> 00:03:29,510
And that's what we're gonna use that options object for the default behavior is to say that any time

49
00:03:29,600 --> 00:03:35,870
an event is received by a subscription it is automatically marked as hey we receive the event.

50
00:03:35,900 --> 00:03:37,130
This thing has been processed.

51
00:03:37,190 --> 00:03:38,960
Everything is good to go.

52
00:03:38,960 --> 00:03:43,550
So the default behavior is if we end up with any kind of air inside of our subscription when we receive

53
00:03:43,550 --> 00:03:46,430
that event the event is essentially lost.

54
00:03:46,460 --> 00:03:50,950
And we do not get some follow up opportunity to process it again or something like that.

55
00:03:50,960 --> 00:03:55,730
Now I wanna repeat for a third time this is the default behavior and we can't change it and we definitely

56
00:03:55,790 --> 00:03:57,110
want to.

57
00:03:57,170 --> 00:04:01,820
The reason we would want to change this default behavior is that maybe there's some really really critical

58
00:04:01,820 --> 00:04:03,710
information inside this event.

59
00:04:03,710 --> 00:04:08,840
For example maybe this event has some information about a payment that a user just made and we need

60
00:04:08,840 --> 00:04:13,820
to make sure that the order service knows that a payment was just created so that we can actually ship

61
00:04:13,820 --> 00:04:15,790
them some goods or something like that.

62
00:04:17,390 --> 00:04:21,770
So we really need to make sure that every single time we receive an event if we end up with any kind

63
00:04:21,770 --> 00:04:28,160
of error we have to somehow figure out how we can reprocess this event or attempt to process it a second

64
00:04:28,160 --> 00:04:30,820
time so to do so.

65
00:04:30,820 --> 00:04:36,340
Like I said we're gonna add an option to this options object in particular we're going to add in an

66
00:04:36,400 --> 00:04:46,190
option called set manual hack mode and we're gonna pass in true like so so what is this option do.

67
00:04:46,200 --> 00:04:52,800
Well as you can kind of guess from the name it sets the manual ak ak is short for acknowledgement mode

68
00:04:52,860 --> 00:04:54,300
to true.

69
00:04:54,340 --> 00:04:59,350
Like I said the default behavior with all of our subscriptions is that as soon as we receive the event

70
00:04:59,910 --> 00:05:04,690
the know that streaming library is going to turn back around to the Net server and say hey we received

71
00:05:04,690 --> 00:05:05,090
the event.

72
00:05:05,110 --> 00:05:06,490
Everything is good to go.

73
00:05:06,760 --> 00:05:12,190
But if we rely upon that default behavior if anything goes incorrectly inside of our message handler

74
00:05:12,190 --> 00:05:13,620
right here then that's it.

75
00:05:13,630 --> 00:05:15,530
We're never gonna hear about this event again.

76
00:05:16,330 --> 00:05:22,510
By setting it manual act mode to true the no not streaming library is no longer going to automatically

77
00:05:22,540 --> 00:05:27,820
acknowledge or tell the Natsumi library that we have received the event and instead it will be up to

78
00:05:27,820 --> 00:05:33,720
you and I to run some processing on that event possibly save some information to the database.

79
00:05:33,820 --> 00:05:40,120
And then after that entire process is complete only after Will we then acknowledge the message and say

80
00:05:40,150 --> 00:05:47,600
OK everything has been processed successfully if we do not acknowledge the incoming event then the Napster

81
00:05:47,700 --> 00:05:49,750
server is going to wait some amount of time.

82
00:05:49,770 --> 00:05:51,750
I believe it's 30 seconds by default.

83
00:05:51,840 --> 00:05:56,940
Then after 30 seconds of not getting an acknowledgement it's going to automatically decide to take that

84
00:05:56,940 --> 00:06:03,420
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

85
00:06:03,630 --> 00:06:08,040
just send it back to the same service again and allow it to give it to have another shot at processing

86
00:06:08,040 --> 00:06:14,560
this thing so let's add on manual act mode of true and then go in to save this file and we're going

87
00:06:14,560 --> 00:06:20,770
to see what happens if we do not add in any code to acknowledge that incoming event is gonna go back

88
00:06:20,770 --> 00:06:22,720
over to my terminal.

89
00:06:22,890 --> 00:06:24,320
Looks like they've both restarted.

90
00:06:24,330 --> 00:06:31,230
They should now be in manual act mode so I'm not going to send another event by doing an R S over here.

91
00:06:31,230 --> 00:06:36,090
So we'll see over here that now the second listener for me has received the event but I am not going

92
00:06:36,090 --> 00:06:41,570
to acknowledge it so right now Nat string server is pretty much just sitting there saying OK I sent

93
00:06:41,580 --> 00:06:43,780
them the event but I haven't heard back yet.

94
00:06:43,800 --> 00:06:49,530
Gee I sure hope everything is going OK and is just sitting twiddling its thumbs waiting to get an acknowledgement

95
00:06:49,530 --> 00:06:50,490
for the event.

96
00:06:50,580 --> 00:06:55,050
But we are not sending it because we are in Matt manual act mode.

97
00:06:55,050 --> 00:07:01,200
You and I have to add in some code to manually say hey we received this event and then after about 30

98
00:07:01,200 --> 00:07:06,720
seconds looks like 30 seconds just past that streaming server eventually gives up and says OK I don't

99
00:07:06,720 --> 00:07:09,030
think they process this event successfully.

100
00:07:09,030 --> 00:07:14,370
I'm just gonna go ahead and send it to another copy or another member of the SKU group or possibly the

101
00:07:14,370 --> 00:07:15,210
same service.

102
00:07:15,240 --> 00:07:20,070
If this thing is not a member of a queue group and so that's why after 30 seconds we saw event number

103
00:07:20,070 --> 00:07:23,130
fifty nine which is the same one up here up here.

104
00:07:23,400 --> 00:07:27,780
Now even for this first copy of the listener we are not going to acknowledge this message either.

105
00:07:27,810 --> 00:07:33,130
So after another 30 seconds Nat streaming server is going to say OK they failed as well.

106
00:07:33,150 --> 00:07:37,860
I'm going to try back with this original person down here so it's going to send off event fifty nine

107
00:07:37,870 --> 00:07:40,960
back to this first one again and again we're not going to acknowledge it.

108
00:07:41,070 --> 00:07:47,720
NATS is gonna wait another 30 seconds and I think you get the idea so we can fix this if we go back

109
00:07:47,720 --> 00:07:53,960
over to our subscription handler right here and then at some point in time inside of here we have to

110
00:07:53,960 --> 00:08:03,040
call MSP dot ACH and that's pretty much it so EC is gonna tell the node Nats streaming library to reach

111
00:08:03,040 --> 00:08:07,830
back out to the Nats streaming server and tell it hey we received the message and it has been processed.

112
00:08:07,960 --> 00:08:15,940
So if we now save this flip makeover we are still processing event number fifty nine.

113
00:08:15,940 --> 00:08:18,390
So that message is still out there in the wild.

114
00:08:18,400 --> 00:08:22,760
Natsumi server is still trying to successfully deliver it to our Q Group.

115
00:08:22,840 --> 00:08:26,050
It's now at some point in time we should see that message appear.

116
00:08:26,080 --> 00:08:30,220
After about 30 seconds or so inside of these two windows one of these two.

117
00:08:30,220 --> 00:08:31,160
And there it is right there.

118
00:08:31,960 --> 00:08:35,230
So now we receive fifty nine for like the fifth time or so.

119
00:08:35,320 --> 00:08:40,180
And as soon as we received it we have now acknowledged that incoming events and since we have acknowledged

120
00:08:40,180 --> 00:08:43,260
it now Natsumi server says Okay it's been delivered.

121
00:08:43,360 --> 00:08:44,170
I'm done.

122
00:08:44,170 --> 00:08:46,790
I don't have to worry about event 59 anymore.

123
00:08:47,170 --> 00:08:52,930
Now quick note if you do not see after restarting the thing if you do not see another console log right

124
00:08:52,930 --> 00:08:55,840
here of event fifty nine or whatever number it is for you.

125
00:08:55,900 --> 00:08:57,660
That is OK.

126
00:08:57,670 --> 00:09:01,890
So as soon as you added in this message shot at right here and then save the file.

127
00:09:01,990 --> 00:09:04,510
If you did not see any further console logs.

128
00:09:04,690 --> 00:09:08,940
Even if you dispatch another event that is totally fine.

129
00:09:09,010 --> 00:09:12,460
I'm going to show you why that is and just a little bit all right.

130
00:09:12,490 --> 00:09:19,350
So in total that is our option of set manual at mode.

131
00:09:19,420 --> 00:09:24,820
We put that in to make sure that we can successfully complete processing and if we do not complete processing.

132
00:09:24,820 --> 00:09:26,270
Maybe there's some air inside of here.

133
00:09:26,350 --> 00:09:31,240
We will not act the message and that means that Nat streaming server is going to try to read delivered

134
00:09:31,240 --> 00:09:35,320
that message again so we get another opportunity to process it.

135
00:09:35,320 --> 00:09:40,450
I apologize for this really long video but as you can guess this manual act mode to true is an extremely

136
00:09:40,450 --> 00:09:45,010
important setting because it's going to make sure that we always get the opportunity to process data

137
00:09:45,250 --> 00:09:49,220
even if something goes wrong in processing it in some earlier attempt.

138
00:09:49,330 --> 00:09:51,630
So let's pause right here and continue in just a moment.