<div dir="ltr">Did you find out anything more on this?<div><br></div><div>There's lots on places in Swift organized around concurrent access to objects - so I think it's probably good that you have that 423 response; your clients will probably see it...</div><div><br></div><div>When you have multiple replicas the proxy's PUT will return shortly after it has a quorum of successful responses - so in that sense it's possible for a client to receive success while at least one node has their reference to that object in hand.  But I'm guessing that's not really your setup?</div><div><br></div><div>Are you *sure* ssbench will never perform concurrent operations to the same file?  Depending on the configuration - processes, total concurrency, number of objects, etc. - it can be a non-trivial problem to coordinate all of that.  ssbench may be doing best effort with no guarantee.</div><div><br></div><div>-Clay</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 31, 2014 at 6:32 PM, jordan pittier <span dir="ltr"><<a href="mailto:jordan.pittier@scality.com" target="_blank">jordan.pittier@scality.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys,<br>
<br>
We are currently benchmarking our Scality object server backend for Swift. We basically created a new DiskFile class that is used in a new ObjectController that inherits from the native server.ObjectController. It's pretty similar to how Ceph can be used as a backend for Swift objects. Our DiskFile is used to make HTTP request to the Scality "Ring" which supports GET/PUT/Delete on objects.<br>
<br>
Scality implementation is here : <a href="https://github.com/scality/ScalitySproxydSwift/blob/master/swift/obj/scality_sproxyd_diskfile.py" target="_blank">https://github.com/scality/ScalitySproxydSwift/blob/master/swift/obj/scality_sproxyd_diskfile.py</a><br>
<br>
We are using SSBench to benchmark and when the concurrency is high, we see somehow interleaved operations on the same object. For example, our DiskFile will be asked to DELETE an object while the object is currently being PUT by another client. The Scality ring doesn"t support multi writers on the same object. So a lot of ssbench operations fail with a HTTP response '423 - Object is locked'.<br>
<br>
We dive into ssbench code and saw that it should not do interleaved operations. By adding some logging in our DiskFile class, we kinda of guess that the Object server doesn't wait for the put() method of the DiskFileWriter to finish before returning HTTP 200 to the Swift Proxy. Is this explanation correct ? Our put() method in the DiskFileWriter could take some time to complete, thus this would explain that the PUT on the object is being finalized while a DELETE arrives.<br>
<br>
Some questions :<br>
1) Is it possible that the put() method of the DiskFileWriter is somehow non blocking ? (or that the result of put() is not awaited?). If not, how could ssbench thinks that an object is completely PUT and that ssbench is allowed to delete it ?<br>
2) If someone could explain me in a few words (or more :)) how Swift deals with multiple writers on the same object, that will be very much appreciated.<br>
<br>
Thanks a lot,<br>
Jordan<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>