[jadmin] jabber14 config questions

[Paul Cahill]

question in line

Matthias Wimmer wrote:
> Paul Cahill schrieb:
>   
>> When we moved from Jabberd 1.42 (Solaris 2.6) to Jabberd14 1.4.4
>> (solaris 9), there were some new config options that I hadn't seen
>> before.   I have them listed below, from the jabber.xml.dist file,
>> followed by my questions
>>
>> Example:
>>     <!--  With the <secret/> element you can configure a fixed dialback
>> secret. You will need this to cluster multiple s2s instances in which
>> case all instances have to use the same dialback secret. If no secret is
>> configured, the server will generate a new random secret on each start. -->
>>      <!-- <secret>somethingSecret</secret> -->
>> Question:  We have about 10 jabber servers that function as the actual
>> IM servers.  These servers talk to eachother and also login to two MUC
>> servers running MUC 0.6 and Jabberd14.  We've had some problems where
>> the MUC server basically stops responding to new requests and the
>> chatrooms take 2 -5 minutes for messages to appear.  A netstat reveals
>> about 450 - 460 established connections to the MUC server.
>>     
>
> I am sorry, but I don't see a question in what you have written. Maybe
> you missed to write your question? :-)
>   
Sorry, the question was - will using the secret make the dialback more 
efficient if it doesn't have to generate it every time?  I believe you 
told us part of the problem is the pthsock (?) under solaris is buggy?  
We are still trying to resolve dialback issues under solaris...although 
I know I still need to implement the s2s in its own process so we can 
restart that more frequently than our nightly server restarts.
>> Example:
>>      <!--  How long we are waiting for an outgoing connection to be
>> established before we bounce pending messages to this server. Default:
>> 30 seconds   -->
>>      <!-- <queuetimeout>30</queuetimeout> -->
>> Question:
>> If we don't have this specified explicitly in the config file what will
>> happen?  If DNS response has a possibility of being slow, should this
>> number be increased?
>>     
>
> This is completely unrelated to DNS. The time for the queuetimeout
> starts _after_ the DNS resolution has been done, when the TCP connect
> has been started. It mesures the time the peer needs to accept a connection.
> If it is not in the configuration file, the default value will be used.
> The default value is 30 seconds.
>
>   
>> Example:
>>      <!--  Close idle server to server connections after this number of
>> seconds. Default: 900 seconds (15 minutes)  -->
>>      <!-- <idletimeout>900</idletimeout> -->
>> Question:
>> similar to the previous question, if this is not in the config file,
>> will the idle connections not time out?
>>     
>
> The will (after 900 seconds). - But is I found out there is a small bug
> in the code. Only fully established connections time out in 1.4.4.
>   
so this could possibly be part of the problem we are having?  Is there 
anything I can do to fix this until 1.5 is released?
>   
>> also, 60% of our servers used multiple host names for virtual servers. 
>> I know this is in the config file comments:
>>   Multiple <host/> entries are allowed - each one is for a
>>    separate virtual server. Note that each host entry must
>>    be on one line, the server doesn't like it otherwise! :)
>>    Use lowercase for the hostname.
>>   But what doesn't the server like about it?  We actually do list them
>> all on the same line and don't have a problem (that we know of) with it
>> and the servers function okay -with the exception to an occasional
>> dialback issue.  Is there a max number of hosts one server should handle?
>>     
>
> This sentence means, that you should not add whitespace (e.g. line
> breaks) between the <host> and </host>. These whitespaces would be
> treated as part of the domain ... and domains are not allowed to have
> whitespace characters.
> It is perfectly legal to have all <host>...</host> entries in the same line.
> There is no codified maximum number of hosts one server can handle. All
> datastructures are resized dynamically.
>
> The only hard limit in jabberd14 is the number of open file descriptors
> (which are mostly used as handled for TCP/IP connections in jabberd14) a
> process can handle. This is not a limit in jabberd14 itself, but in
> libpth which is used by jabberd14. This limit is 1024 descriptors.
>
>
> Tot kijk
>     Matthias
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PaulC.vcf
Type: text/x-vcard
Size: 253 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/jadmin/attachments/20061108/d24acd14/PaulC-0004.vcf