Browse code

sworker: docs update to reflect use with event_route[core:pre-routing]

Daniel-Constantin Mierla authored on 26/11/2020 12:44:27
Showing 1 changed files
... ...
@@ -17,11 +17,20 @@
17 17
 	<title>Overview</title>
18 18
 	<para>
19 19
 		This module can delegate processing of SIP requests to a group of
20
-		workers in the configuration file. The async workers have to defined
21
-		with the global parameter.
20
+		workers in the configuration file by using event_route[core:pre-routing].
21
+		The async workers have to defined with the global parameter. The worker
22
+		process that received the message internally does the usual execution
23
+		of the config script, running request_route or reply_route.
22 24
 	</para>
23 25
 	<para>
24
-		It does not create the transaction and nor suspend it.
26
+		Note: the behaviour is different than the async module, because it does
27
+		not create the transaction (obviously also not performing suspend).
28
+	</para>
29
+	<para>
30
+		Note: it does not propagate anything set in the event_route, therefore
31
+		any set flag, or avp, etc. are lost. The SIP message is processed by the
32
+		delegated worker as it was fresh received from the network (including
33
+		parsing).
25 34
 	</para>
26 35
 	</section>
27 36
 
... ...
@@ -88,14 +97,19 @@ request_route {
88 97
 		<function moreinfo="none">swork_task(gname)</function>
89 98
 		</title>
90 99
 		<para>
91
-		Delegate the processing of SIP message to a group of async workers.
100
+		Delegate the processing of SIP message to a group of async workers. The
101
+		function is restricted to be used inside event_route[core:pre-routing].
92 102
 		</para>
93 103
 		<para>
94 104
 		The parameter gname provides the name of the group workers, it can
95 105
 		contain pseudo-variables.
96 106
 		</para>
97 107
 		<para>
98
-		The function returns 0 (exit) in case the task is delegated.
108
+		The function returns 1 (true) in case the task is delegated. After that,
109
+		'drop' must be used so processing of the message does not continue to
110
+		request_route or reply_route in the same process, it is going to be done
111
+		by the delegated group of workers. It returns -1 (false) in case there
112
+		was a proble delegating the processing.
99 113
 		</para>
100 114
 		<para>
101 115
 		This function can be used from REQUEST_ROUTE|CORE_REPLY_ROUTE.
... ...
@@ -104,11 +118,10 @@ request_route {
104 118
 		<title><function>sworker_task()</function> usage</title>
105 119
 		<programlisting format="linespecific">
106 120
 ...
107
-request_route {
108
-	if(!sworker_active()) {
121
+event_route[core:pre-routing] {
122
+	if(sworker_task("default")) {
109 123
 		xinfo("===== delegate processing [$Tf] [$si:$sp]\n");
110
-		sworker_task("default");
111
-		exit;
124
+		drop;
112 125
 	}
113 126
 	xinfo("===== processing continues [$Tf] [$si:$sp]\n");
114 127
     ...