Chetan, Ok, I saw the rename part now. I hadn't read the actual code before. Really the problem cannot be addressed until the true bottleneck is found. That means we would need to know precisely which line of the code is taking too long, or longer than expected. It shouldn't be too hard to throw in some timing logging, or use a profile to know where the slowness is. Problem was not well enough described to know more at this point.
Best regards, Clay Ferguson [email protected] On Fri, Nov 11, 2016 at 12:15 AM, Chetan Mehrotra <[email protected] > wrote: > Hi Clay, > > Looking at the modified file [1] the change was done in rename flow. > So first temporary file gets created and then in new impl its copied > to final file via channel copy > > > Chetan Mehrotra > [1] http://jackrabbit.510166.n4.nabble.com/file/n4665414/ > FileDataStore.java > > > On Fri, Nov 11, 2016 at 11:38 AM, Clay Ferguson <[email protected]> wrote: > > Chetan, > > I thought he was saying the uploading was slow. Not renaming. I may be > > wrong. Forgive me if I missed some part of this. > > > > Best regards, > > Clay Ferguson > > [email protected] > > > > > > On Thu, Nov 10, 2016 at 11:46 PM, Chetan Mehrotra < > [email protected] > >> wrote: > > > >> Interesting. This means that rename operation as per Jave on NFS is > >> performing slowly while a copy via FileChannel is performing better? > >> Can you provide some numbers here and NFS mount details. > >> > >> As so far my understand was that if a file is already created in NFS > >> mount and then the rename operation should be fast i.e. O(1) instead > >> of being a function of size > >> Chetan Mehrotra > >> > >> > >> On Thu, Nov 10, 2016 at 10:25 PM, hsp <[email protected]> wrote: > >> > Hi, > >> > > >> > We use persistence with DataStore using a path that maps to a remote > NAS, > >> > using NFS. > >> > With the default configuration in > >> > org.apache.jackrabbit.core.data.FileDataStore it was causing too much > >> delay > >> > to upload the files from server to the NAS. > >> > To workaround this we implemented a option in FileDataStore that uses > >> > java.nio.Channels.FileChannel and performs better than the default > way, > >> over > >> > a version 2.10.0. > >> > Would be better (less error prone for us) if this implementation > could be > >> > part of the api build. > >> > The configuration in repository.xml would be added with a parameter in > >> > DataStore element: > >> > > >> > > >> > <DataStore class="org.apache.jackrabbit.core.data.FileDataStore"> > >> > > >> > > >> > > >> > > >> > </DataStore> > >> > > >> > > >> > In our code, the parameter REMOTEPERSISTENCEBYNFS is hardcoded so > far... > >> > Our environment server is with: > >> > linux SUSE SLES 11 sp3, kernel "3.0.101-0.15-default" > >> > 4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181440) (eager to > >> upgrade > >> > to Java 8 and wildFLy10 as soon as possible, probably next year) > >> > JVM: 1.6.0_27 > >> > > >> > I would be glad if you can suggest ideas or better approach to solve > this > >> > "neck" in the process to save a file. > >> > > >> > We are waiting for version 2.14 of jackrabbit, hoping not to have to > >> > generate a parallel version of it, ;-). > >> > > >> > The file is attached, sorry by not make only a diff file. > >> > > >> > Best Regards, > >> > Helio. FileDataStore.java > >> > <http://jackrabbit.510166.n4.nabble.com/file/n4665414/ > FileDataStore.java > >> > > >> > > >> > > >> > > >> > > >> > -- > >> > View this message in context: http://jackrabbit.510166.n4. > >> nabble.com/Use-FileDataStore-with-NFS-SAN-NAS-tp4665414.html > >> > Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > >> >
