What version of glusterfs are you using? It might be either * a stale metadata issue. * inconsistent ctime issue.
Can you try turning off all performance xlators? If the issue is 1, that should help. On Fri, Dec 28, 2018 at 1:51 AM Dmitry Isakbayev <[email protected]> wrote: > Attempted to set 'performance.read-ahead off` according to > https://jira.apache.org/jira/browse/AMQ-7041 > That did not help. > > On Mon, Dec 24, 2018 at 2:11 PM Dmitry Isakbayev <[email protected]> > wrote: > >> The core file generated by JVM suggests that it happens because the file >> is changing while it is being read - >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8186557. >> The application reads in the zipfile and goes through the zip entries, >> then reloads the file and goes the zip entries again. It does so 3 times. >> The application never crushes on the 1st cycle but sometimes crushes on the >> 2nd or 3rd cycle. >> The zip file is generated about 20 seconds prior to it being used and is >> not updated or even used by any other application. I have never seen this >> problem on a plain file system. >> >> I would appreciate any suggestions on how to go debugging this issue. I >> can change the source code of the java application. >> >> Regards, >> Dmitry >> >> >> _______________________________________________ > Gluster-users mailing list > [email protected] > https://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list [email protected] https://lists.gluster.org/mailman/listinfo/gluster-users
