search for: remote_open

Hi, I think, there is missing constructor function supporting remote writing for XapianWritableDatabase class in the php bindings (0.9.7). This code: $db = new XapianWritableDatabase(remote_open($db_host, $db_port), $action); returns: Fatal error: No matching function for overloaded 'new_XapianWritableDatabase' (...) $db = new XapianWritableDatabase($path, $action); works fine. xapian-tcpsrv is running with --writable parameter. Tom

Hi, I'm trying to use xapian from php script with TCP daemon. I started TCP daemon: xapian-tcpsrv --port 5050 --writable /path-to-db When I trying to get access to it within my php-script with remote_open_writable("localhost", 5050) or remote_open("localhost", 5050) apache fails with signal 11: dev kernel: pid 35923 (httpd), uid 80: exited on signal 11 TCP demon also shows me different errors: Connection from 127.0.0.1, port 62652 Got exception NetworkError: write failed (conte...

...an-tcpsrv --port 5050 --writable /var/lib/xapian/objects/ I indexed all ths stuff we need and tested the search. Fast and furious, but i randomly get: REMOTE:Unable to acquire database write lock on /var/lib/xapian/objects/: already locked First, this is a connection tried to open with Xapian::remote_open. So i think it should'nt create a write lock. Otherwise, i started xapian-tcpsrv with -- writable, do i have to start to instances on the same directory, one writable and one not? Second, if i understand the examples right i have to unset the database object to get the lock released. But i...

...o, for whatever reason. The reason why it fails, I think, is that Xapian::Remote::open is probably not supported on Win32. When I realized it, I finally managed to exclude from the (provided) SWIG-generated xapian_wrap.cc the unsupported lines, and to "gently" raise an exception when remote_open() is called. Here is the patch for python/modern/xapian_wrap.cc: --- xapian_wrap.cc_ORIG Fri Mar 25 16:42:49 2005 +++ xapian_wrap.cc Fri Mar 25 17:53:18 2005 @@ -15350 +15350,2 @@ - +// remote_open should be removed to wrap in Win32/MinGW32 +#ifndef NO_REMOTE_OPEN @@ -15597,0 +15599,6 @@ +#else...

...o, for whatever reason. The reason why it fails, I think, is that Xapian::Remote::open is probably not supported on Win32. When I realized it, I finally managed to exclude from the (provided) SWIG-generated xapian_wrap.cc the unsupported lines, and to "gently" raise an exception when remote_open() is called. Here is the patch for python/modern/xapian_wrap.cc: --- xapian_wrap.cc_ORIG Fri Mar 25 16:42:49 2005 +++ xapian_wrap.cc Fri Mar 25 17:53:18 2005 @@ -15350 +15350,2 @@ - +// remote_open should be removed to wrap in Win32/MinGW32 +#ifndef NO_REMOTE_OPEN @@ -15597,0 +15599,6 @@ +#else...

...erver be a deferent machine from the server that xapian is installed on. With my test code using local database ($db_path = "/var/xapain_db/default"; $db = new_database($db_path);) a query takes around 0.012 seconds on the same machine with the connection changed to use tcp ($db = remote_open('127.0.0.1',3055);) the same query takes 129 seconds or times out. I am currently trying to follow tcpsrv via the debuger however so far everything looks reasonable ! Any ideas would be well received. environment: HP G4 2X3.6Ghz 2Gb ram, mandrake 2005, xapian 0.9.2 Roger -- No vir...

Hi all, We've struck a problem when using remote queries and hoping someone can offer some guidance. I haven't managed to get a C++ reproduction in the test suite, but I have got a demo that fails using Python: import xapian db = xapian.remote_open('localhost', 8100) qp = xapian.QueryParser() qp.set_database(db) query = qp.parse_query('test') enq = xapian.Enquire(db) enq.set_query(query) enq.get_mset(0, 10) This script fails with: xapian.InvalidArgumentError: REMOTE:Bad serialised query I've tracked it dow...

Hi I am using Xapian 1.012 here, trying to optimise the search preformance. My testing suit has 10M docs of forum threads, DB only indexed the thread title, author name, category name, and 1 optional serialize value(0) which is the unix dateline DB_full indexed all the DB terms + thread contents After couple tests, I decided to remove ALL anchor terms such as SHOW_PUBLIC, MORE_IMPORTANT