Forum Discussion

nitinrahim's avatar
nitinrahim
Brass Contributor
Jan 02, 2024

Replace Operation Cosmos Db

Hi Team,   We have noticed that during millisecond interval sequential operations (create, read, replace operations happening in very small interval) for some records even though we don't get an er...
mannu2050's avatar
mannu2050
Icon for Microsoft rankMicrosoft
Jan 02, 2024

nitinrahim you will definitely get a response if your request is reaching to database, Azure Cosmos DB is designed to have very high concurrency, it does billions of concurrent transactions. Basis your explanation it may be that during high concurrency the client app getting challenges, please refer https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/performance-tips-java-sdk-v4?tabs=api-async to follow best practices from client side. If it doesn't solve the issue then I will recommend you to raise a support ticket. 

  • nitinrahim's avatar
    nitinrahim
    Brass Contributor
    Jan 03, 2024

    Thanks Manish and Jill.

     

    We did notice we had response code 449 on certain replaceitem requests but on upsertItem we had 200 response for the same loadtest. Any specific reason why replace operation can encounter 449's with the same load while upsertitem won't and what does that imply?

     

    With Regards,

    Nitin Rahim

    • mannu2050's avatar
      mannu2050
      Icon for Microsoft rankMicrosoft
      Jan 04, 2024

      449 error generated when you do multiple operations on the same document at the same second. This happens during load test when there is a skewness of sample values and you end up concentrating all of load to specific values. It can come up with any of the methods you have mentioned. 

      • nitinrahim's avatar
        nitinrahim
        Brass Contributor
        Jan 04, 2024

        Thanks Manish.

         

        We are loading sequentially only (1 record create, then read the same document then replace/upsert as mentioned above all immediately though) and then second document for testing purpose. We noted that consistently throughout this test that 449 happens's only on 'replace' operations. Upsert positively gives a '200' OK response. And we ran the same test after deleting data many times and we see this behavior. So was checking regarding any atomicity or database specific (with respect to consistency etc) property differences with respect to replace and upsert operations? And if we receive 449s do we need to manually retry ( or a specific retry logic) those 449 response codes so the SDK will retry or had retried already? We did see 449's on Create operations before but thats not related this this discussion scope.

         

        With Regards,

        Nitin Rahim

Resources