Unfortunately I cannot provide a sample. This is a rather large product. It’s why great lengths were made to build a massive gatling simulation.
Good advice looking at wsActor! I turned on debug logging in the logback.xml with
`
`
so I could get some logger.debug statements in wsActor. I ran this a few times with
Before a sample actor was hung, it printed the following (commentary in red):
`
10:41:57.663 [DEBUG] i.g.h.a.a.w.WsActor - Sending message check on WebSocket ‘gatling.http.webSocket’: TextMessage(3:::{
“destination”:“AuditLogService”,
“messageType”:“AddAuditLog”,
“data”:{
“eventType”:12,
“userId”:-100,
“personId”:-100,
“objectType”:11,
“objectName”:“Multiple Alarms Selected”,
“info”:“ids: 112,113,114”
},
“method”:“post”,
“_tracker”:“13f70147-74f3-4f75-bbd8-92f3fd0e3c92” ← _tracker looked for in the TrackedResponseRegex
}) ← The request sent before the check gets stuck
10:41:57.663 [DEBUG] i.g.h.a.a.w.WsActor - setCheck blocking=true timeout=2 seconds ← The corresponding AddAuditLog check looking for the TrackedResponseRegex
10:41:57.681 [DEBUG] i.g.h.a.a.w.WsActor - Check on WebSocket ‘gatling.http.webSocket’ timed out ← old check timing out
10:41:57.799 [DEBUG] i.g.h.a.a.w.WsActor - Received text message on websocket ‘gatling.http.webSocket’:3:::{“destination”:“TaskService”,“messageType”:“ActiveTasks”,“data”: …
… “method”:“subscribe”,"_tracker":“a4904910-4f6a-4450-bb6a-7dfd55ed9686”,“clientAddr”:“10.128.72.85”} ← subscribed response from old request, note the _tracker doesn’t match
`
We have a few requests that will send multiple responses when specified with “method”:“subscribe”. The request from “destination”:“TaskService”,“messageType”:“ActiveTasks” is among them. This request had already sent one response, and it’s check had passed. It’s check (defined in WebsocketRequest) uses .until(1), so it was expecting just one response to succeed it’s check. The server will send more responses, but they should be ignored because they don’t pass the new checks.
We ran this under different configurations where it hung in different places. Whenever the actor was hung, it was after it received another text message from a subscribe response.
Looking at wsActor onTextMessage, It should be looking at the current check (set in this case by the “destination”:“AuditLogService”,“messageType”:“AddAuditLog” request, which also just expects a response back with a matching _tracker). This leads to a few questions:
-
L156 implicit val cache = mutable.Map.empty[Any, Any]
What’s up with this? I don’t see a cache being used anywhere.
-
L158 check.check(message, tx.session) match {
Should compare the current AddAuditLog check to the message, which should be a failure and pattern match to L172. That doesn’t hang the actor, does it? I don’t think so…
-
L154 tx.check.foreach { check =>
Because we are using wsAwait and no other nonblocking checks, tx.check has only whatever checks haven’t timed out in the last two seconds. This certainly includes the current check just set by AddAuditLog. Is this correct? Could it also still have the passed check from A****ctiveTasks?
- Am I wrong that multiple responses from our subscribe requests are not ignored by the new checks?
Monsieur Landelle, your assistance is wonderful. Thank you for all your help! It is immensely appreciated.