Child Item

Performance of Dropbox getCurrentAccount

I'm running one of the Dropbox samples and getting very slow (>30 seconds) response on a call to getCurrentAccount().

The code looks like this:

...
DbxRequestConfig config = new DbxRequestConfig(APPNAME);
client = new DbxClientV2(config, ACCESS_TOKEN);
FullAccount account = client.users().getCurrentAccount();
...

In our tests, the call to "client.users().getCurrentAccount()" runs for about 30 seconds before returning. This is running against the dropbox-core-sdk-3.1.5 JAR file.

Any idea why getCurrentAccount() would be so slow?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Thanks for the report. This isn't occurring for me, so we'll need to narrow this down. Can you let me know:

Is this only occurring when retrieving the information for one account in particular, or does it also happen for other accounts?
Is this occurring for other methods as well?

tdgvrr

We've tried three accounts - all seem to perform about the same (all are "PRO" accounts, if that matters).

A few other details that might help:

This is a command-line tool - we authenticate with a access token we generated on the website.
All of the other methods seem to run fine....in the snippet I sent, from program start to the getCurrentAccount call runs in about two seconds - then getCurrentAccount consistently runs from 20-40 seconds.
This is running on a small but dedicated server with a Gigabit connection - nothing else we do is slow over the network.
The results are repeatable...it's not like it just randomly occurs.
We're using Java 1.8 (161).

tdgvrr

I wanted to add that we discovered the problem isn't unique to "getCurrentAccount" - whichever method we call first after these two lines of code seems to take 30 seconds or so:

DbxRequestConfig config = new DbxRequestConfig(APP_NAME);
DbxClientV2 client = new DbxClientV2(config, ACCESS_TOKEN);

We skipped the call to getCurrentAccount() and found the same issue on listFolder(), download(), etc. Seems like whichever function we call first seems to suffer this 30 second penalty.

Is there some sort of tracing built into the API that might show us what's going on at a lower level?

Greg-DB

Thanks for the additional information. I don't know off hand what may be causing that, and I can't reproduce that behavior myself using that same code. We'll have to dig into it further.

You may be able to get some more logging output using:

Logger.getLogger("").setLevel(Level.ALL);
final java.util.logging.ConsoleHandler consoleHandler = new java.util.logging.ConsoleHandler();
consoleHandler.setLevel(Level.ALL);
Logger.getLogger("").addHandler(consoleHandler);

Please share the output if you get any other useful information when using that.