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
We use mq-mqi-nodejs 0.9.17 in a ms that receives HTTP requests from clients puts them on a queue and waits for response on another queue using the request message id.
Sending single requests works well, but when load testing by sending several requests at a time the MQ GET gets stuck after a random number of requests (even that a timeout is specified in the get request) and freezes the application.
Moreover, in one case it returned the wrong data belonging to another request.
My question is: did you ever performed tests of the package in a scenario that I described ?
To solve temporarily we did a very nasty workaround by putting the GET inside a section locked with a mutex but this makes all
requests to be executed sequentially which is not how it should work.
The text was updated successfully, but these errors were encountered:
I have done some stress testing, though it's not likely to be an exact match for yours. There was a fix put into v0.9.23 that affected some of the async retrieval. Tt doesn't immediately sound like the same thing, but it might help.
We use mq-mqi-nodejs 0.9.17 in a ms that receives HTTP requests from clients puts them on a queue and waits for response on another queue using the request message id.
Sending single requests works well, but when load testing by sending several requests at a time the MQ GET gets stuck after a random number of requests (even that a timeout is specified in the get request) and freezes the application.
Moreover, in one case it returned the wrong data belonging to another request.
My question is: did you ever performed tests of the package in a scenario that I described ?
To solve temporarily we did a very nasty workaround by putting the GET inside a section locked with a mutex but this makes all
requests to be executed sequentially which is not how it should work.
The text was updated successfully, but these errors were encountered: