Openfire Dev : Openfire Properties : Comments

RE: Openfire Properties

communityadmin@igniterealtime.org — Sat, 22 Dec 2007 10:08:18 GMT

This is a really great idea - I didn't know there were so many properties.

RE: Openfire Properties

communityadmin@igniterealtime.org — Sat, 22 Dec 2007 10:10:46 GMT

As an aside, for disabling the admin ports, it shows \-1 is the '\' a delimiter ?

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 07 Jan 2008 15:50:08 GMT

Then, what does "TODO" mean?

It isn't implemented yet, so I can't use right now?

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 07 Jan 2008 15:54:10 GMT

Martyn: No, the '\' is an error in importing this web page from the old wiki, it shouldnt be there at all.

africa1971: TODO means the property is used in the source somewhere, but it has not been documented yet.

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 07 Jan 2008 15:57:20 GMT

Thanks, slushpupie.

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 07 Jan 2008 16:02:28 GMT

Thanks Slushpupie, this is a very useful repository of the properties used by Openfire.

Perhaps we could have a basic 'default' set of properties configured on first install, with the defaults added on upgrade if they don't exist ?

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 07 Jan 2008 16:04:28 GMT

Martyn,

Im not sure I follow- isn't that what the "Default" column provides?

RE: Openfire Properties

communityadmin@igniterealtime.org — Tue, 08 Jan 2008 07:48:34 GMT

Sorry, I meant that rather than the properties being 'default' but not in the DB table, we have a default set in the table.

For instance, I only found out the RSS feed could be disabled because I found a referance for it - if it was in the table, but the default setting is enabled, it would be easier to find. Does that make sense ?

RE: Openfire Properties

communityadmin@igniterealtime.org — Tue, 08 Jan 2008 14:37:02 GMT

Ok, that makes sense. However the way things are done now that isnt likely to happen, as it would take rewriting every instance in the source a property is grabbed.

RE: Openfire Properties

communityadmin@igniterealtime.org — Tue, 08 Jan 2008 16:26:02 GMT

OK, it's not a problem, I just wondered if it would have made things easier for people if they could see the entries in the table.

What about populating the table on a first install ? would that be simple enough, without causing code to be re-written ?

RE: Openfire Properties

communityadmin@igniterealtime.org — Tue, 08 Jan 2008 16:43:18 GMT

I see JiveGlobals.getIntProperty("xmpp.client.idle", 6601000)/1000 in the source code for xmpp.client.idle, not 30 * 60 * 1000.

RE: Openfire Properties

communityadmin@igniterealtime.org — Fri, 11 Jul 2008 15:09:20 GMT

Thank you so much, this is very helpful!

RE: Openfire Properties

communityadmin@igniterealtime.org — Sun, 13 Jul 2008 03:18:47 GMT

I got error when trying to set to -1 on console text field, it says

"Please type a valid port number or restore to default".

But setting it in /opt/openfire/conf/openfire.xml all works fine

and the port no longer stays open after OF restart.

RE: Openfire Properties

communityadmin@igniterealtime.org — Sun, 13 Jul 2008 03:20:58 GMT

msg above is about disable access to OF console via port 9090, allowing only 9091 https connections.

RE: Openfire Properties

communityadmin@igniterealtime.org — Sat, 31 Jan 2009 05:52:03 GMT

xmpp.client_ssl.processing.threads

number of threads to use to process incoming SSL connections
DEFAULT = 16 (integer)

xmpp.client.cert.policy

SSL client certification policy
DEFAULT = "disabled" (string)
OTHER KNOWN VALUES = "needed", "wanted"

xmpp.socket.plain.active

whether to listen for unencrypted socket connections from clients
DEFAULT = true (boolean)

xmpp.socket.ssl.active

whether to listen for SSL socket connections from clients
DEFAULT = true (boolean)

xmpp.component.socket.active

whether to listen for socket connections from components
DEFAULT = false (boolean)

xmpp.server.socket.active

whether to listen for socket connections from other servers
DEFAULT = true (boolean)

xmpp.multiplex.socket.active

whether to listen to multiplexed socket connections from other servers (maybe for clustering?)
DEFAULT = false (boolean)

xmpp.socket.plain.port

which port to listen for incoming unencrypted socket connections
DEFAULT = 5222 (int)

xmpp.socket.ssl.port

which port to listen for incoming SSL socket connections
DEFAULT = 5223 (int)

xmpp.component.socket.port

which port to listen for incoming external component connections
DEFAULT = 5275 (int)

xmpp.server.socket.port

which port to listen for incoming external server connections
DEFAULT = 5269 (int)

xmpp.multiplex.socket.port

which port to listen for incoming multiplex connections
DEFAULT = 5262 (int)

xmpp.socket.backlog

socket listening backlog queue length
DEFAULT = 50 (int)

xmpp.socket.buffer.receive

low level socket receiving buffer size
DEFAULT = -1 (int)

xmpp.socket.buffer.send

low level socket sending buffer size
DEFAULT = -1 (int)

xmpp.socket.linger

low level socket linger (?)
DEFAULT = -1

xmpp.socket.tcp-nodelay

DEFAULT = ? (boolean)

xmpp.processor.count

the number of threads (-1) in the pool to accept socket connections
DEFAULT = Runtime.getRuntime().availableProcessors() (the number of processors available to the JVM, int)

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 20 Apr 2009 10:33:12 GMT

Anyone tested the xmpp.client.idle ? Doesn;t seem to work.

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 20 Apr 2009 12:29:00 GMT

Hi Pakmee, I remember playing with it before and it did seem to work. Can't remember the detail now. What specifically are you trying and what is not working?

Cheers,Mark

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 20 Apr 2009 12:35:33 GMT

The xmpp.client.idle doesn't seem to work. i checked the db in ofproperty and the xmpp.client.idle is set to 60000 which is equivalent to 1min unless it is not in millis. I am trying to make sure that the user gets disconnected if he is idle. I.e I tried logging in then just unplugging my ethernet cable but for some reason the user stays active in the openfire session and is not getting kicked as it should if it is idle. I really don't want to have to go down the route of implementing a timer bean that consistently checks the user's session before kicking them since this is a function that has been implemented in openfire unless I am not doing it right.

Many thanks.

RE: Openfire Properties

communityadmin@igniterealtime.org — Tue, 21 Apr 2009 10:13:51 GMT

Any ideas on why this would happen ?

RE: Openfire Properties

communityadmin@igniterealtime.org — Wed, 22 Apr 2009 13:45:54 GMT

Hello again, sorry for spamming this thread but I am getting desperate. I still cannot figure out why the xmpp.client.idle will not work. Is that something that actually hasn't been implemented in 3.6.3 ? Any other way to force the user out if he is idle for more than i.e 10mins instead of having to use the xmpp.client.property or a timer bean ?

Thanks.

RE: Openfire Properties

communityadmin@igniterealtime.org — Wed, 22 Apr 2009 18:55:22 GMT

all we can do is to file this JM-1533 and to wait till someone look into this

RE: Openfire Properties

communityadmin@igniterealtime.org — Wed, 22 Apr 2009 19:40:32 GMT

thanks . I just wanted to know if it was working for other people but seems like no one has been using it .

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 21 May 2009 07:46:06 GMT

Hello there. Not really sure if this is the right place to post regarding an issue, but xmpp.muc.tasks.log.timeout is not working on version 3.6.4.The default value of 300000 is too high for me, so I set it to 2500 (2,5s) but even after a restart of the openfire program it does not care about it. I am using Gentoo and java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode)

I am using MySQL as database and have verified that entries are indeed logged to ofMucConversationLog, just not in the timely manner as I want.

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 21 May 2009 08:05:30 GMT

Well, maybe there are more system properities not working properly, but only the developers can answer that. Maybe you should also ask on the forums. Maybe this setting cant be set lower than 300000.

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 21 May 2009 08:30:09 GMT

Imo, none of these timeout properties seem to be working properly, that is why I resorted to writing my own custom servlets to take care of timeouts etc..

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 21 May 2009 09:11:10 GMT

Please tell me more about this servlet.

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 21 May 2009 09:20:37 GMT

U can expose a servlet via the openfire plugin and do whatever u want with openfire. I.e i am currently facing issues whereby the users never get kicked out. So I wrote a plugin that checks the sessions of everyone active and see how long they have been active for. I.e if system.currenmil - lastactive > i.e 120000 (2mins) , then i close the session. Try to look on the forum or google. There should be something there.

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 21 May 2009 17:25:02 GMT

Best thing to do is grab a copy of the source code from svn, search the code yourself for the property you want to use and see what the actual code is doing with it. It's usually pretty straightforward and compiling your own version of Openfire is super super easy on a linux box.

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 21 May 2009 18:27:01 GMT

not so hard on a winbox either i'm not a coder and i manage to compile spark/openfire with Netbeans

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 21 May 2009 18:31:48 GMT

Lol for the icing on cake,

I have to mention that i am using mac osx to compile openfire and this is also dead easy.

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 18 Jun 2009 17:38:14 GMT

I added a bunch of xmpp.pubsub.* properties. I have only used xmpp.pubsub.multiple-subscriptions and xmpp.pubsub.sysadmin.jid myself and can confirm that they work.

RE: Openfire Properties

communityadmin@igniterealtime.org — Fri, 19 Jun 2009 09:18:24 GMT

how can I change the users session timeout ?? (logged in the server)

because the xmpp.server.session.timeout is TODO

and I used it and it doesnt do anything!

RE: Openfire Properties

communityadmin@igniterealtime.org — Fri, 19 Jun 2009 11:07:35 GMT

TODO means it's not yet implemented, so it doesnt work obviously. And i think this property is for server to server connection. What do you ant to achieve with such option? Maybe you want idle clients to be logged off? Then xmpp.idle is the option you need, but it seems it doesnt work (i've filed a bug report) or works only sometimes.

RE: Openfire Properties

communityadmin@igniterealtime.org — Fri, 19 Jun 2009 13:36:12 GMT

lol any idea when those subtle issues will b fixed. they are pretty important imo. i worked around some ofthem but still pretty annoying

RE: Openfire Properties

communityadmin@igniterealtime.org — Fri, 19 Jun 2009 16:20:28 GMT

Unless someone provides patches.

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 10 Aug 2009 05:56:17 GMT

The granularity of xmpp.pubsub.multiple-subscriptions is the whole Openfire. Is there any plan to implement a more finer-grained control of multi-subscribe feature as described in XEP-0060, Section 6.1.6?

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 31 Aug 2009 17:31:37 GMT

In the code i noticed the property

xmpp.pep.enabled

for people looking to turn off XEP-0163

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 09 Nov 2009 19:45:29 GMT

What is the default value for the property xmpp.httpbind.client.requests.wait ?

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 07 Jan 2010 15:30:46 GMT

Does anyone know if a restart is required after changing the mail.smtp.host value? My value was very wrong, and after correcting it my problems still persist.

Thanks

RE: Openfire Properties

communityadmin@igniterealtime.org — Thu, 14 Jan 2010 16:15:23 GMT

Can java system properties can be set via openfire web console --> system properties ?

like below ones

Property name Value

com.sun.jndi.ldap.connect.timeout      5000

etc.

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 19 Apr 2010 08:31:15 GMT

In theory setting

ldap.pagedResultsSize= some_positive_integer

will trigger Ldap Paged results. So it will be possible to fetch more than 1000 records from AD

RE: Openfire Properties

communityadmin@igniterealtime.org — Mon, 17 May 2010 15:14:09 GMT

xmpp.muc.history.maxNumber = 0 does not appear to work for us. Also set with this: xmpp.muc.history.type and tried "none" and "0" but the conference rooms still show previous conversations. Everything else works GREAT so far. LDAP is a significant advantage.

RE: Openfire Properties

communityadmin@igniterealtime.org — Wed, 08 Jun 2011 19:49:28 GMT

Can someone please update the list? Thanks