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
Currently we have a message queue for external call (SIAK web scraping/update matkul). Every time an 'update matkul' request is triggered, a new message connection and channel will be created. However the connections never close 'gracefully', always forced by inactivity exactly 3 minutes after the request sent. Sure the message is ACKed properly, but this behaviour keep spamming our Sentry with error logs like StreamConnectionError (on the server side) and error: missing heartbeat (on the RabbitMQ log)
Requested behavior:
Close the connection properly. I've tried .close() on each end of the update jadwal request, but I found that the connection was established from a pool. So every .close() command just breaks and auto-regenerate the connection.
Why this behavior is better:
We will save logs and perhaps preventing unpredictable behavior such as too much connection, especially when our server is on high load.
I will provide screenshots if necessary.
The text was updated successfully, but these errors were encountered:
This issue is a:
Current behavior:
Currently we have a message queue for external call (SIAK web scraping/update matkul). Every time an 'update matkul' request is triggered, a new message connection and channel will be created. However the connections never close 'gracefully', always forced by inactivity exactly 3 minutes after the request sent. Sure the message is ACKed properly, but this behaviour keep spamming our Sentry with error logs like StreamConnectionError (on the server side) and error: missing heartbeat (on the RabbitMQ log)
Requested behavior:
Close the connection properly. I've tried .close() on each end of the update jadwal request, but I found that the connection was established from a pool. So every .close() command just breaks and auto-regenerate the connection.
Why this behavior is better:
We will save logs and perhaps preventing unpredictable behavior such as too much connection, especially when our server is on high load.
I will provide screenshots if necessary.
The text was updated successfully, but these errors were encountered: