RE: 1.9.x JavaHL: long initial delay when performing a log

> -----Original Message-----
> From: Marc Strapetz [mailto:marc.strapetz_at_syntevo.com]
> Sent: vrijdag 13 maart 2015 20:34
> To: dev_at_subversion.apache.org
> Subject: 1.9.x JavaHL: long initial delay when performing a log
>
> I'm experiencing a strange initial delay when performing a log using JavaHL.
>
> svn log http://svn.apache.org/repos/asf/subversion/branches/1.8.x
>
> shows first results after 2-3 seconds, while following code snippet
> takes at least 20 seconds (sometimes significantly more, might depend on
> the server's load):
>
> ISVNRemote session =
> factory.openRemoteSession("http://svn.apache.org/repos/asf");
>
> List<String> paths =
> Collections.singletonList("subversion/branches/1.8.x");
>
> session.getLog(paths, Revision.SVN_INVALID_REVNUM, 0, 0, false,
> false, false, null, new LogMessageCallback() {
> public void singleMessage(Set<ChangePath> changedPaths,
> long revision, Map<String, byte[]> revprops, boolean hasChildren) {
> System.out.println("DATA");
> }
> });
>
> Once the log responds, a bunch of revisions are reported, so it seems
> that there is some kind of caching of log records.
>
> I've tested with latest 1.9.x sources on Windows but have seen the same
> behavior with javahl-1.8-extensions branch on Linux, too.

I can only find a server side buffering... But this might explain what you see.

Our server reports use an apr feature that buffers +- 8 KByte data before sending out the first data.

In this specific JavaHL case you ask for just the revision numbers. (Unlike the C api, JavaHL's session.getLog() appears to handle a null list of revision properties as no revision properties. Not the standard set!)

I think every revision would (encoded in our Xml protocol) cost about 70 bytes, so there would fit at least 100 revisions in that buffer.

For each of these revisions the apr repository has to handle a security check for every changed path... And many branch revisions involve more than a few paths.

This looks like an extremely worst case for this operation. The first 100 revisions would have to be fully processed before you get the first result.

I think a patch like the one attached should fix most of the usecases without affecting server performance too much... But it has to be applied at the server.
(I'm trying to create a testcase to see how much this helps)

        Bert