Open 0xmichalis opened 5 years ago
That's interesting - are you able to share what the requests look like? There's actually a new command-line switch requestsDumpDir
that logs everything to a directory.
These transaction write conflicts are coming from MongoDB and the server is probably supposed to automatically retry the transaction. However I don't understand how resource creations can cause such conflicts..
Sure, it's a record generated by synthea (record.tar.gz). Note that I am using the same record in all of those parallel requests and rely on the fact that every time a new resource is PUT, the server will return the created resource with its new ID.
I have reproduced write conflict errors when processing that bundle but only during the first transactions.. Running it again with lots of concurrency then works fine. I don't quite understand why it happens but perhaps something to do with some one-off index work that takes a database-wide lock. Do you also see the first transaction(s) failing or intermittent failures?
My context is tests running in parallel - when run serially (or with the same X-Mutex-Name
set on every request), I don't see this issue.
But when you run them in parallel how often do transactions fail? Can you attach log output? Thanks.
When multiple processes try to write to the fhir server, the requests fail with write conflicts. I am able to work around this issue by using the
X-Mutex-Name
header documented here but I was wondering whether this issue is meant to be fixed appropriately by having some sort of deterministic concurrency control baked into the server.ps.1 The writes in the server are independent resources in my case (they are all resource creations).
ps.2 I am using the all-in-one image that bakes Mongo in it.