[jcifs] JCIFS pagination

[Sridhar Jonnalagadda]

Hi Mike & Chris,

Appreciate your response.

I'm trying to consolidate both of your responses and provide more inputs on
my requirement.

Based on your feedback, I need to provide more inputs to make it more clear.

Clarifications:

1. listFiles API will be not be changed.

2. There will be new API(s) to SmbFile, which takes page size as input and
return array based on the size. This means page size is not specific to my
needs. This API can be called multiple time to retrieve page worth of
details until all elements are retrieved.

3. Yes, it is specific to my application needs to support pagination. The
server is handling request from mobile devices. Mobile devices are
requesting to view contents of SMB share. Since SMB share volumes keeps
growing and, server need to handle multiple clients concurrently, there
should be a way to handle thousands of clients by limiting memory usage. To
do this only option is to support pagination.

4. Since JCIFS is blocking API, I took care in my application to make it
look like asynchronous. I was thinking about users out there who might get
benefit of making it as async library.

5. For my application sorting is not a concern. Does CIFS / SMB server
protocol support sorting?

6. My concern is let say, the share has 1,000 objects and, 1000 devices
trying to use the API, then all of them together might be using significant
amount of memory.


I changed SmbFile to have three new public APIs. These APIs help me to
provide iteration behavior and keep memory usage at minimum possible.

1.  public SmbFile[] getFirstPageContents(final SmbFileFilter
fileFilter,final SmbFilenameFilter fileNameFilter, int pageSize) throws
SmbException
2.  public SmbFile[] getNextPageContents() throws SmbException
3.  public void endPaginationRequest()


There are couple of additions constructors.

1.  Trans2FindFirst2( String filename, String wildcard, int
searchAttributes, int pageSize )
2. Trans2FindNext2(final  int sid, final int pageSize, final int resumeKey,
final String filename )

At present I'm testing the changes and would like to contribute this
change. Please let me know the process.


Thanks & Regards,
Sridhar Jonnalagadda.

On Sun, Oct 26, 2014 at 1:22 AM, Michael B Allen <ioplex at gmail.com> wrote:

> On Wed, Oct 22, 2014 at 6:49 PM, Sridhar Jonnalagadda
> <jonnalagadda.sridhar at gmail.com> wrote:
> > Hello JCIFS support team,
> >
> >
> >
> > We have a requirement where there will be multiple calls, to list
> contents
> > of a folder. From MS-CIFS doc, there are two commands TRANS_FIND_FIRST2
> and
> > TRANS_FIND_NEXT2 that might be used to retrieve folder contents as pages.
> >
> >
> >
> > The listFiles() API in SmbFile is retrieving all the contents as one big
> > list. I see the code is using TRANS_FIND_FIRST2 and TRANS_FIND_NEXT2.
> > SmbFile does not have API to fulfill the requirement.
>
> Hi Sridhar,
>
> JCIFS commands are already async. And JCIFS is very efficient about
> memory and stuff like this. All you need is the
> {SmbFileFilter,SmbFilenameFilter}.accept() callback. No need for OOP
> and Observable "patterns" and all that jazz.
>
> Although from just glancing at the code, it seems if you throw an
> exception from {SmbFileFilter,SmbFilenameFilter}.accept() it will not
> properly call SmbComFindClose2. But that is just a bug in the code
> that looks fairly easy to fix (by putting the close call in a finally
> block). I have added it to the TODO list. But if you really want to
> quit the list op early, you can probably still safely throw an
> exception in accept(). It might leave a handle open on the server but
> it will get cleaned up when the connection closes (after being idle
> for 30 seconds).
>
> Mike
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20141027/7ee5bec7/attachment.html>