Thanks everyone - I'm using XCC 4.1.3 with a server that is at version 4.1.6, so possibly a problem there?
I'm using ThreadPoolExecutor to manage the threads. I would have a used more abstract ExecutorService, but I thought I needed some fine-grained control for some reason I can no longer remember. I've run into the issue when using 4 threads on my 2-core 1-cpu desktop. The server wasn't heavily loaded - this is our dev environment. Also - and this is weird - I get the errors consistently in my tests; the behavior tends to be repeatable; it doesn't have the usual intermittent inconsistency I would expect from race conditions. I'll try updating the XCC version and report back. -Mike On 10/25/2011 12:20 PM, Michael Blakeley wrote: > I don't recall seeing that error with XQSync, Corb, or RecordLoader - all of > which I use with large numbers of threads via java.util.concurrent pools. > Usually I configure 2 client threads per server CPU thread. > > Is it possible that you are using an older XCC jar, and hitting a bug that's > already been fixed? > > Are you managing your threads directly? I'd recommend against that: it's all > too easy to make mistakes, and java.util.concurrent provides a great > abstraction layer. > > -- Mike > > On 25 Oct 2011, at 07:40 , Mike Sokolov wrote: > > >> I've been experimenting with a multithreaded document loader; I get a >> substantial speedup, which is great. I'm inserting documents using the >> java XCC API. Every now and then though, I get a >> RequestPermissionException with the message >> >> "Authorization failed for user 'xxxx'" >> >> If I retry the insertion immediately, it invariably succeeds, although >> the exception has isRetryAdvised() == false. >> >> I'm sure the authentication is the same for all these requests. I get >> this error even when none of the documents have the same uri; so there >> shouldn't be any conflicts or race conditions related to which thread >> wins, at least not anything obvious like trying to write the same >> document twice. At least I'm pretty sure that's not it? >> >> I'll send something to support I guess, but before doing the work to >> wrap this up in a neat reproducible package I thought I'd see if anyone >> had run into this before - anyone? >> >> -- >> Michael Sokolov >> Engineering Director >> www.ifactory.com >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> >> > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
