That's a v. good suggestion.
On Tue, Feb 7, 2012 at 5:00 PM, Florentine, George
george.florent...@flatironssolutions.com wrote:
One little trick we've found useful on these kind of loosely coupled file
transfer architectures is to transmit a small file AFTER the big file
transfer is complete
Hi Folks,
I have 4 nodes [All mixed DNode+ENode] across cluster. I am using server
fields to store a map that consists of user-id and registered query-id
mapping. When I am trying to get server field value by pointing one node
of the cluster it is returning different registered query id than
MarkLogic server fields are specific to the host.
If you have a load balancer in front of the MarkLogic servers one solution
is to set the session sticky bit so that a client session always goes to
the same MarkLogic host.
On Wed, Feb 8, 2012 at 12:02 PM, Abhishek53 S abhishek5...@tcs.com
True, but server-fields may be overkill for this problem.
Registered queries have used consistent hashing since some 4.x revision. So the
simplest implementation is to register the query every time. It will always get
the same id, and it will only do the work if the query was not previously
I emailed about a week ago about a problem I was having with XCC and large
files. I got some very good advice which said I needed to use
session.insertContent to get the file in. I'm done with that conversion
but dealing with the resulting problems due to the change.
What I'm looking at right
I'm using xdmp:zip-create() to create a zipfile which I can download or copy
it to my local Windows file system via webdav, but it seems that the zipfile
contens cannot be read. Is there some trick to creating the zipfile so that
I can extract the contents on my local filesystem after downloading
Hi Mike,
I'm storing the zipfile using xdmp:document-insert, in which case I have
been able to extract the contents using xdmp:zip-get(). I can't seem to
save it using xdmp:save to my unix file system. Maybe I need to save to the
MarkLogic mount and not to my user account... Anyhow, here's the
That looks reasonable enough. Maybe the problem is something to do with webdav?
Here's what I see with 5.0-2 and cadaver 0.23.3, both on OS X.
$ cadaver http://localhost:7000/
dav:/ get aaa.zip
Downloading `/aaa.zip' to aaa.zip:
Progress: [=] 100.0% of 129 bytes
In an effort to expand the MarkLogic Community to a broader audience of
developers, students, educators and professionals, we are migrating our site's
name from developer.marklogic.comhttp://developer.marklogic.com to
community.marklogic.com. This transition is starting today and you can now
Hi Mike,
I found the problem:
Using a part with a forward slash, i.e., part/test.xml/part, implies
that there is a blank parent directory. Opening the zipfile on Windows 7
without a directory name provides no means for drilling down into the empty
subdirectory. The remedy is to remove the
Hi Josh,
Your first line doesn’t show where the BOM is located. It should be the
first two characters of the first line. Note: the encoding attribute in the
XML pi, doesn’t ensure it really is written in that encoding, though is a
strong suggestion usually. Particularly if the file is written
11 matches
Mail list logo
