Gluster users - Apr 2015 - Synchronous replication, or no?

We have a Gluster replicated setup with 2 servers. Each server also runs an
app server that functions as a client of the gluster files. Client access
to the appservers are load balanced using round robin.

Sometimes, when a client creates a new file and then immediately tries to
read it, the read fails because the appserver cannot find it. If the client
sleeps for about 1 second between creating the file and reading it, the
read always succeeds.

I was under the impression that gluster replication was synchrounous, so
the appserver would not return back to the client until the created file
was replicated to the other server. But this does not seem to be the case,
because sleeping a little bit always seems to make the read failures go
away. Is there any other reason why a file created is not immediately
available on a second request?

I am running 3.6.2 and have not configured anything special except
storage.owner-id and auth.allow.

Thanks!
Eric Mortensen
Appstax Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20150409/a64e2ac1/attachment.html>

On 04/09/2015 04:39 PM, Eric Mortensen wrote:
> We have a Gluster replicated setup with 2 servers. Each server also 
> runs an app server that functions as a client of the gluster files. 
> Client access to the appservers are load balanced using round robin.
>
> Sometimes, when a client creates a new file and then immediately tries 
> to read it, the read fails because the appserver cannot find it. If 
> the client sleeps for about 1 second between creating the file and 
> reading it, the read always succeeds.
>
> I was under the impression that gluster replication was synchrounous, 
> so the appserver would not return back to the client until the created 
> file was replicated to the other server. But this does not seem to be 
> the case, because sleeping a little bit always seems to make the read 
> failures go away. Is there any other reason why a file created is not 
> immediately available on a second request?
>
> I am running 3.6.2 and have not configured anything special except 
> storage.owner-id and auth.allow.
If I understand correctly, creates are happening from one mount and 
reads are happening from another mount?

What do you mean by read failing? Does it give any error? or the data 
read is not complete?

Pranith
>
> Thanks!
> Eric Mortensen
> Appstax Technologies
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20150409/178e0d20/attachment.html>

> I was under the impression that gluster replication was synchrounous, so
the
> appserver would not return back to the client until the created file was
> replicated to the other server. But this does not seem to be the case,
> because sleeping a little bit always seems to make the read failures go
> away. Is there any other reason why a file created is not immediately
> available on a second request?
It's quite possible that the replication is synchronous (the bits do hit
disk before returning) but that the results are not being seen immediately
due to caching at some level.  There are some GlusterFS mount options
(especially --negative-timeout) that might be relevant here, but it's also
possible that the culprit is somewhere above that in your app servers.