Re: XML-RPC syntax - changed for 1.1b - in what way ??

["hans@seesite.be" <ha...@seesite.be>]

OK, finaly found it.

The xml-rpc syntax has changed indeed for xindice-1.1b.
The new format looks like

<methodCall>
<methodName>run</methodName>
<params>
<param><value><struct>
<member><name>collection</name><value><string>/db</string></value></member>
<member><name>message</name><value><string>ListCollections</string></value></member>
</struct></value>
</param>
</params>
</methodCall>

(and a member document for document-inserts)

>
> In the message,
>
> http://marc.theaimsgroup.com/?l=xindice-users&m=104955883212261&w=2
>
> Someone pointed out that xml-rpc syntax changed :
>
> Does anyone now in what way?? please ? I'm realy stuck here.
>
> It used to look like :
>
> POST /Xindice HTTP/1.0
> User-Agent: PHP XMLRPC 1.0
> Host: 127.0.0.1
> Content-Type: text/xml
> Content-Length: 174
>
> <?xml version="1.0"?>
> <methodCall>
> <methodName>db.listCollections</methodName>
> <params>
> <param>
> <value><string>/db</string></value>
> </param>
> </params>
> </methodCall>
>
> what would te new format look like?
>
> whenever there is a xml-rpc request, in tomcat logs/xindice_log comes an 
> entry like,
>
> 2003-05-29 14:45:22 StandardContext[/Xindice]: Mapping 
> contextPath='/Xindice' with requestURI='/Xindice' and relativeURI=''
> 2003-05-29 14:45:22 StandardContext[/Xindice]:  Mapped to servlet 
> 'Xindice' with servlet path '' and path info 'null' and update=true
>
> How should I interpret this? Are the empty values (path info) caused by a 
> wrong rpc-xml request, or Are those tomcat params that should be set??
>
> Any help would be greatly appreciated!
> greets,
> Hans
>
>
>
>
>
>

Re: BTreeFiler not available

["hans@seesite.be" <ha...@seesite.be>]

The error,

DEBUG> Filer 'org.apache.xindice.core.filer.BTreeFiler' not available

was caused because linux has a default maximum of 1024 open files.
Seems like the more collections and indexers you have, the more open files.

I solved the problem by setting the value for open files higher.
this can be done (on linux) by the command.

#ulimit -n 5000

don't know yet what the downside on other processes or system-load is, or 
could be.