You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Jasmin presumes messages are received in order so concatenation occurs with the last received one.
Example
Message: "Um dois três quatro cinco seis sete oito nove dez onze doze treze quatorze quinze dezasseis dezassete dezoito dezanove vinte vinte e um vinte e dois vinte e três vinte e quatro"
Logs from Jasmin:
2016-12-01 15:17:42 INFO 1 DeliverSmContent[33b06aee-ba4f-4c30-b2ff-07b743475be2] is part of long msg of (3), will be enqueued after concatenation.
2016-12-01 15:17:43 INFO 1 DeliverSmContent[bd9e5925-b5da-4839-9cd5-afd4fec2f90d] is part of long msg of (3), will be enqueued after concatenation.
2016-12-01 15:17:44 WARNING 1 Received the last part (msg_ref_num:44) and did not find all parts in redis, data lost !
2016-12-01 15:17:44 INFO 1 DeliverSmContent[4cd8fae1-8cbc-47ae-80a8-d6492bbc43f3] is part of long msg of (3), will be enqueued after concatenation.
The text was updated successfully, but these errors were encountered:
@kissonde this is the actual behaviour of Jasmin for handling incoming deliver_sm long messages, making Jasmin handle unordered incoming PDUs can be planned in next releases.
You still can request a commercial to prioritize this feature for actual release plan (0.9), if it's the case then send an email to [email protected] or follow the steps on the customer portal.
Not sure why,but I changed some source code to support this https://github.com/jookies/jasmin/blob/master/jasmin/managers/listeners.py line 444
Before if segment_seqnum == total_segments: hvals = yield self.redisClient.hvals(hashKey) if len(hvals) != total_segments: self.log.warn( 'Received the last part (msg_ref_num:%s) and did not find all parts in redis, data lost !', msg_ref_num) return
After hvals = yield self.redisClient.hvals(hashKey) if len(hvals) == total_segments:
@farirat do we have any fix planned for this issue in coming releases to handle unordered incoming PDUs? It appears this issue hasn't been fixed in the latest release(011.0) as well
Jasmin presumes messages are received in order so concatenation occurs with the last received one.
Example
Message: "Um dois três quatro cinco seis sete oito nove dez onze doze treze quatorze quinze dezasseis dezassete dezoito dezanove vinte vinte e um vinte e dois vinte e três vinte e quatro"
tcpdump content:
15:17:42.020043 IP (tos 0x18, ttl 44, id 53915, offset 0, flags [DF], proto TCP (6), length 230)
41.78.18.15.2775 > 172.17.0.6.39858: Flags [P.], cksum 0x1f35 (correct), seq 4098514301:4098514491, ack 3250417520, win 5840, length 190
0x0000: 4518 00e6 d29b 4000 2c06 93ea 294e 120f E.....@.,...)N..
0x0010: ac11 0006 0ad7 9bb2 f44a 5d7d c1bd 6f70 .........J]}..op
0x0020: 5018 16d0 1f35 0000 0000 00be 0000 0005 P....5..........
0x0030: 0000 0000 0000 27d1 0001 0132 3434 3933 ......'....24493
0x0040: 3035 3136 3531 3400 0001 3435 3532 3800 0516514...45528.
0x0050: 4000 0000 0000 0008 008c 0500 032c 0301 @............,..
0x0060: 0055 006d 0020 0064 006f 0069 0073 0020 .U.m...d.o.i.s..
0x0070: 0074 0072 00ea 0073 0020 0071 0075 0061 .t.r...s...q.u.a
0x0080: 0074 0072 006f 0020 0063 0069 006e 0063 .t.r.o...c.i.n.c
0x0090: 006f 0020 0073 0065 0069 0073 0020 0073 .o...s.e.i.s...s
0x00a0: 0065 0074 0065 0020 006f 0069 0074 006f .e.t.e...o.i.t.o
0x00b0: 0020 006e 006f 0076 0065 0020 0064 0065 ...n.o.v.e...d.e
0x00c0: 007a 0020 006f 006e 007a 0065 0020 0064 .z...o.n.z.e...d
0x00d0: 006f 007a 0065 0020 0074 0072 0065 007a .o.z.e...t.r.e.z
0x00e0: 0065 0020 0071 .e...q
15:17:42.182060 IP (tos 0x18, ttl 44, id 53916, offset 0, flags [DF], proto TCP (6), length 40)
41.78.18.15.2775 > 172.17.0.6.39858: Flags [.], cksum 0x8741 (correct), seq 4098514491, ack 3250417537, win 5840, length 0
0x0000: 4518 0028 d29c 4000 2c06 94a7 294e 120f E..(..@.,...)N..
0x0010: ac11 0006 0ad7 9bb2 f44a 5e3b c1bd 6f81 .........J^;..o.
0x0020: 5010 16d0 8741 0000 P....A..
15:17:43.330024 IP (tos 0x18, ttl 44, id 53917, offset 0, flags [DF], proto TCP (6), length 230)
41.78.18.15.2775 > 172.17.0.6.39858: Flags [P.], cksum 0x1dab (correct), seq 4098514491:4098514681, ack 3250417537, win 5840, length 190
0x0000: 4518 00e6 d29d 4000 2c06 93e8 294e 120f E.....@.,...)N..
0x0010: ac11 0006 0ad7 9bb2 f44a 5e3b c1bd 6f81 .........J^;..o.
0x0020: 5018 16d0 1dab 0000 0000 00be 0000 0005 P...............
0x0030: 0000 0000 0000 27d2 0001 0132 3434 3933 ......'....24493
0x0040: 3035 3136 3531 3400 0001 3435 3532 3800 0516514...45528.
0x0050: 4000 0000 0000 0008 008c 0500 032c 0302 @............,..
0x0060: 0075 0061 0074 006f 0072 007a 0065 0020 .u.a.t.o.r.z.e..
0x0070: 0071 0075 0069 006e 007a 0065 0020 0064 .q.u.i.n.z.e...d
0x0080: 0065 007a 0061 0073 0073 0065 0069 0073 .e.z.a.s.s.e.i.s
0x0090: 0020 0064 0065 007a 0061 0073 0073 0065 ...d.e.z.a.s.s.e
0x00a0: 0074 0065 0020 0064 0065 007a 006f 0069 .t.e...d.e.z.o.i
0x00b0: 0074 006f 0020 0064 0065 007a 0061 006e .t.o...d.e.z.a.n
0x00c0: 006f 0076 0065 0020 0076 0069 006e 0074 .o.v.e...v.i.n.t
0x00d0: 0065 0020 0076 0069 006e 0074 0065 0020 .e...v.i.n.t.e..
0x00e0: 0065 0020 0075 .e...u
15:17:43.492103 IP (tos 0x18, ttl 44, id 53918, offset 0, flags [DF], proto TCP (6), length 40)
41.78.18.15.2775 > 172.17.0.6.39858: Flags [.], cksum 0x8672 (correct), seq 4098514681, ack 3250417554, win 5840, length 0
0x0000: 4518 0028 d29e 4000 2c06 94a5 294e 120f E..(..@.,...)N..
0x0010: ac11 0006 0ad7 9bb2 f44a 5ef9 c1bd 6f92 .........J^...o.
0x0020: 5010 16d0 8672 0000 P....r..
15:17:44.501746 IP (tos 0x0, ttl 44, id 8996, offset 0, flags [DF], proto TCP (6), length 180)
41.78.17.146.2775 > 172.17.0.6.49180: Flags [P.], cksum 0xe90c (correct), seq 626243076:626243216, ack 3625781797, win 5840, length 140
0x0000: 4500 00b4 2324 4000 2c06 4429 294e 1192 E...#$@.,.D))N..
0x0010: ac11 0006 0ad7 c01c 2553 b604 d81d 0a25 ........%S.....%
0x0020: 5018 16d0 e90c 0000 0000 008c 0000 0005 P...............
0x0030: 0000 0000 0000 0960 0001 0132 3434 3933 .......`...24493
0x0040: 3035 3136 3531 3400 0001 3435 3532 3800 0516514...45528.
0x0050: 4000 0000 0000 0008 005a 0500 032c 0303 @........Z...,..
0x0060: 006d 0020 0076 0069 006e 0074 0065 0020 .m...v.i.n.t.e..
0x0070: 0065 0020 0064 006f 0069 0073 0020 0076 .e...d.o.i.s...v
0x0080: 0069 006e 0074 0065 0020 0065 0020 0074 .i.n.t.e...e...t
0x0090: 0072 00ea 0073 0020 0076 0069 006e 0074 .r...s...v.i.n.t
0x00a0: 0065 0020 0065 0020 0071 0075 0061 0074 .e...e...q.u.a.t
0x00b0: 0072 006f .r.o
1
We get:
Logs from Jasmin:
2016-12-01 15:17:42 INFO 1 DeliverSmContent[33b06aee-ba4f-4c30-b2ff-07b743475be2] is part of long msg of (3), will be enqueued after concatenation.
2016-12-01 15:17:43 INFO 1 DeliverSmContent[bd9e5925-b5da-4839-9cd5-afd4fec2f90d] is part of long msg of (3), will be enqueued after concatenation.
2016-12-01 15:17:44 WARNING 1 Received the last part (msg_ref_num:44) and did not find all parts in redis, data lost !
2016-12-01 15:17:44 INFO 1 DeliverSmContent[4cd8fae1-8cbc-47ae-80a8-d6492bbc43f3] is part of long msg of (3), will be enqueued after concatenation.
The text was updated successfully, but these errors were encountered: