I'm having a problem with moving titles in a queue. I get an etag mismatch on the second move even though I'm sending the etag I get back from the previous move. If I don't send etags, moves work fine. This code used to work, so something seems to have changed on the server side. We've had several other etag issues discussed on this forum, and frankly I've reached the point where I distrust the whole etag mechanism.
I'm seeing this as well. I can successfully fetch a queue and store the etag, then move a title while sending the etag I got with the queue request. That move works fine, and I store the response etag. When I go to move the title again (sending along the new etag), the request fails with: "status_code": "412", "message": "queue out of Date ETag mismatch".
What's odd is, if I do each step very slowly (with, say, about 10 to 15 seconds between moves, I can move the title several more times before I get that failure, though it's not a constant number of moves). I've double- and triple-checked to make sure I'm storing and sending the most up-to-date etag, as well.
Something seems very odd about this situation. Any insight would be appreciated!
Update: Here's a simpler example... Fetch the contents of a user's disc queue and receive etag 10730942414. Initiate a title move and send along etag 10730942414 (same), and get the above failure message about being out of date.
What's most troublesome about this issue is that it doesn't happen every time -- it works about 3 out of 5 times. This makes it seem like something on the server side isn't catching up, as I'm doing the move fairly quickly after receiving the queue, but well within the range of user operation.
Yeah, I totally understand your frustration, Rich, with your experiences with etags. I'm sorry it looks like we have something bizarre going on. Let me investigate this, my initial thoughts from your symptoms are that we have some caching issues going on. I'll investigate and let you know..
I'd be frustrated too about this, but please bear with us on this, etags can be so useful with performance, and I'm really sorry we are messing this up for y'all!!
Update on this: We have identified the issue being with our load balancing. We have had issues with this before where it sometimes throws a random request to the wrong server. We thought it was resolved, but apparently it is not. We are in the process of reverting the current Load balancing configuration,and the issue should go away..
ok we have reverted to our previous load balancer configuration, so this should problem should dissappear. Let me know if you are still running to these issues.
That appeared to fix the issues for me -- I can move titles over and over very quickly (as fast as my UI permits) with no errors. Thank you! Here's hoping that fixed your issues, as well, Rich!
I'm having a problem with moving titles in a queue. I get an etag mismatch on the second move even though I'm sending the etag I get back from the previous move. If I don't send etags, moves work fine. This code used to work, so something seems to have changed on the server side. We've had several other etag issues discussed on this forum, and frankly I've reached the point where I distrust the whole etag mechanism.
Message edited by Rich Knox 3 years ago
Tags
Command-Tab – 3 years ago
I'm seeing this as well. I can successfully fetch a queue and store the etag, then move a title while sending the etag I got with the queue request. That move works fine, and I store the response etag. When I go to move the title again (sending along the new etag), the request fails with: "status_code": "412", "message": "queue out of Date ETag mismatch".
What's odd is, if I do each step very slowly (with, say, about 10 to 15 seconds between moves, I can move the title several more times before I get that failure, though it's not a constant number of moves). I've double- and triple-checked to make sure I'm storing and sending the most up-to-date etag, as well.
Something seems very odd about this situation. Any insight would be appreciated!
Command-Tab – 3 years ago
Update: Here's a simpler example... Fetch the contents of a user's disc queue and receive etag 10730942414. Initiate a title move and send along etag 10730942414 (same), and get the above failure message about being out of date.
What's most troublesome about this issue is that it doesn't happen every time -- it works about 3 out of 5 times. This makes it seem like something on the server side isn't catching up, as I'm doing the move fairly quickly after receiving the queue, but well within the range of user operation.
mikey – 3 years ago
Yeah, I totally understand your frustration, Rich, with your experiences with etags. I'm sorry it looks like we have something bizarre going on. Let me investigate this, my initial thoughts from your symptoms are that we have some caching issues going on. I'll investigate and let you know..
I'd be frustrated too about this, but please bear with us on this, etags can be so useful with performance, and I'm really sorry we are messing this up for y'all!!
=-mikey-=
mikey – 3 years ago
Update on this: We have identified the issue being with our load balancing. We have had issues with this before where it sometimes throws a random request to the wrong server. We thought it was resolved, but apparently it is not. We are in the process of reverting the current Load balancing configuration,and the issue should go away..
=-mikey-=
mikey – 3 years ago
ok we have reverted to our previous load balancer configuration, so this should problem should dissappear. Let me know if you are still running to these issues.
=-mikey-=
Command-Tab – 3 years ago
That appeared to fix the issues for me -- I can move titles over and over very quickly (as fast as my UI permits) with no errors. Thank you! Here's hoping that fixed your issues, as well, Rich!
Rich Knox – 3 years ago
This seems to be working for me now too. Thanks!