Rohan, This is caused due to an issue with the current timeout logic which bails out lock calls (which can potentially take longer than the configured timeout). We are working on a fix for it. Please use a more suitable transport-timeout till the fix is available. avati 2008/4/30 Rohan <rohan.thale@xxxxxxxxxxxxxxxx>: > Hi, > > > > I'm getting following error in client. Any help? > > > > > > 2008-04-30 15:00:41 W [client-protocol.c:204:call_bail] GFS-ACT-ST-002-1: > activating bail-out. pending frames = 1. last sent = 2008-04-30 15:00:27. > last received = 2008-04-30 15:00:12 transport-timeout = 10 > > 2008-04-30 15:00:41 C [client-protocol.c:211:call_bail] GFS-ACT-ST-002-1: > bailing transport > > 2008-04-30 15:00:41 W [client-protocol.c:4759:client_protocol_cleanup] > GFS-ACT-ST-002-1: cleaning up state in transport object 0x2aaaac003350 > > 2008-04-30 15:00:41 E [client-protocol.c:4809:client_protocol_cleanup] > GFS-ACT-ST-002-1: forced unwinding frame type(1) op(30) > reply=@0x2aab6c6e9340 > > 2008-04-30 15:00:41 E [client-protocol.c:4140:client_lk_cbk] > GFS-ACT-ST-002-1: no proper reply from server, returning ENOTCONN > > 2008-04-30 15:00:41 E [afr.c:3126:afr_lk_cbk] bricks: > (path=/active18code-staging/active18/invite.php child=GFS-ACT-ST-002-1) > op_ret=-1 op_errno=107 > > 2008-04-30 15:00:41 E [fuse-bridge.c:2361:fuse_setlk_cbk] glusterfs-fuse: > 2304541: ERR => -1 (107) > > > > Rohan > -- If I traveled to the end of the rainbow As Dame Fortune did intend, Murphy would be there to tell me The pot's at the other end.
