ldaptive: org.ldaptive.ad.control.util.DirSyncClient cookie not replayed in requests

[GoogleCodeExporter]

For example, the execute() method looks at the cookie, ensures it is valid, and 
then still calls createRequestControls(null) instead of with the cookie 
argument:

  public Response<SearchResult> execute(
    final SearchRequest request,
    final Response<SearchResult> response)
    throws LdapException
  {
    final byte[] cookie = getDirSyncCookie(response);
    if (cookie == null) {
      throw new IllegalArgumentException(
        "Response does not contain a dir sync cookie");
    }

    final SearchOperation search = new SearchOperation(connection);
    request.setControls(createRequestControls(null));
    return search.execute(request);
  }

I'm having trouble using your example to subscribe to a stream of changes, and 
I think this is the reason. It would be great if the example also let me save 
the cookie byte[] so I can pick up where I left off (which I perceive as the 
main reason folks will want to use the DirSyncControl).

Thanks,

Martin

Original issue reported on code.google.com by mar...@mbs3.org on 10 Apr 2013 at 5:30

[GoogleCodeExporter]

Looking at the code I think you are correct. Unfortunately, all of our testing 
revolved around the #executeToCompletion method. I'll commit a fix to the 
snapshot.

In terms of persisting the cookie, what sort of API are you looking for?

Original comment by dfis...@gmail.com on 10 Apr 2013 at 6:06

• Changed title: ldaptive: org.ldaptive.ad.control.util.DirSyncClient cookie not replayed in requests
• Changed state: Accepted

[GoogleCodeExporter]

Latest snapshot has been updated and can be downloaded at:
http://www.ldaptive.org/download/ldaptive-1.0.1-SNAPSHOT-dist.zip

Original comment by dfis...@gmail.com on 10 Apr 2013 at 6:41

[GoogleCodeExporter]

Attached is an example of what I was trying to get done. Compare that to the 
original DirSyncClient. I'm basically trying to run a utility on some interval 
and get the incremental differences since the last time I ran them.

In short, I:
 1. adjusted the constructor to take a cookie storage file arg
 2. added methods to save and read the cookie to that file
 3. adjusted executeToCompletion to read and write that cookie

I think you're right that the other two execute methods aren't really designed 
around repeated calls, so I left them alone.

Thanks!

Martin Smith

Original comment by mar...@mbs3.org on 10 Apr 2013 at 6:48

Attachments:

• PersistentDirSyncClient.java

[GoogleCodeExporter]

Thanks for that attachment it provided some clarity.
I think a simple interface for cookie management would be useful and should 
plug cleanly into the current implementation.
The same sort of problem exists in the SyncReplClient as well, so hopefully 
this will be reusable.
I'll commit a patch tomorrow for your review.

Original comment by dfis...@gmail.com on 11 Apr 2013 at 10:43

[GoogleCodeExporter]

See r2694.

Original comment by dfis...@gmail.com on 12 Apr 2013 at 8:55

[GoogleCodeExporter]

So this change would allow you to provide your own persistence implementation:
{code}
    final File fCookieStorage = ....;
    client.executeToCompletion(
      request,
      new CookieManager() {

        @Override
        public byte[] readCookie()
        {
          if(fCookieStorage == null || !fCookieStorage.canRead()) {
            return null;
          }
          return FileUtils.readFileToByteArray(fCookieStorage);
        }

        @Override
        public void writeCookie(byte[] cookie)
        {
          FileUtils.writeByteArrayToFile(fCookieStorage, cookie);
        }
      }
    );
{code}

Thoughts?

Original comment by dfis...@gmail.com on 16 Apr 2013 at 3:36

[GoogleCodeExporter]

Hey! Thanks so much for following up on this. This is exactly the kind of thing 
I would use. For processing larger datasets, you may want to add a cookie 
manager option/argument to the other 'execute...' implementations as well (your 
executeToCompletion tries to load every change into memory, which won't work 
for large AD implementations -- those users will likely use the other execute 
methods).

Thank you!
Martin

Original comment by mar...@mbs3.org on 16 Apr 2013 at 6:08

[GoogleCodeExporter]

Thanks for filing this issue Martin. Fix scheduled for the 1.0.1 release.

Original comment by dfis...@gmail.com on 16 Apr 2013 at 9:43

• Changed state: Fixed