It's not quite that simple.
Have a look at addOrReplaceDocumentWithException(). The following code
computes the file name given the URI:
>>
// Establish a session
getSession();
FileOutputConfig config = getConfigParameters(null);
FileOutputSpecs specs = new
Hi Karl,
I'm happy to submit a patch with the issue.
I have not read deeply into the framework API's, but I tested a simple "hack"
to pass to the StringBuffer constructor and it worked:
StringBuffer path = new StringBuffer(outputDescription.substring(0,
outputDescription.length() - 1));
Hi David,
This is not the expected behavior. The removeDocument() method should be
looking for the existence of the root directory, and returning if that
doesn't exist, before attempting to remove the specified document.
Please create a ticket, and if you are interested, create a patch.
Hi Olivier,
Zookeeper connections are pooled, so they are pulled out of the pool at
will by ManifoldCF and returned when the lock etc is done. This means you
really should need only a total number of outstanding Zookeeper handles
that is on the same order as the number of operating threads in
Hi all,
Just to clarify my concern on ZK:
To my knowledge, best practices concerning ZK connections are to not go beyond
60. Is there any rationale for setting it at 1000 for MCF ?
Could this can have side effects on our ZK cluster shared by MCF and SolrCloud ?
Thanks,
Olivier
> Le 23 oct.
Using ManifoldCF v 2.8.1: I think there is a problem with the Filesystem
Output Connector's removeDocument method.
During testing, we noticed that documents removed from the source
repository did not result in a zero-length file in the file system
destination.
When the "removeDocument()" method
