Re: UNSUBSCRIBE
UNSUBSCRIBE Best Regards Xia Bo email: bestxi...@gmail.com tel: +86 186 8181 5975 2014/1/8 Auro Tripathy > UNSUBSCRIBE >
Re: Roster module with custom MySQL requests
Le 07/01/2014 13:22, Tomasz Sterna a écrit : object-sequence is used mainly for sorting - to keep stanza ordering, etc. There is no enforcement on uniqueness, but in cases when you do care on ordering, these should be unique. In roster table you should be fine with just incrementing ver. BTW, you could just write your UPDATE queries setting ver with next sequence number for the table. It will save you incrementing in code and keep it in line with how the original module does things. I can have something like "UPDATE `roster-items` SET `object-sequence`=`object-sequence`+1" but his break uniqueness in the table. I haven't found any easy ways to do something similar with LAST_INSERT_ID() or AUTO_INCREMENT in MySQL, hence my question. I think I'll stick to that for now. My bet is that loading user data for packet delivery causes that. There is an old item on Rob's TODO list, to have two load-user events - one when user logs in, and other used for delivery, which loads only necessary user data. But it is still TODO Ok thanks. If performances really become an issue for me, I may get the time to look into that. One of the reasons we have memory pools in jabberd2. Just to check : you're talking about the pools in "pool.h". For the record, group management in the roster do not seem to use them. If I'm correct, every time an user changes groups, there are potential mallocs/frees. Same goes for _roster_user_load. Maybe at one point it'll be better to use pools for roster items too (item, item->name, item->groups and its content). I've not yet profiled anything, but this may be a way to improve speed when loading user data for packet delivery (without having to code 2 load-user events). Then again, I'll focus on the features I need for now. Perf issues will come later. -- Sylvain "Gugli" Guglielmi
UNSUBSCRIBE
UNSUBSCRIBE
Re: Cannot connect with android clients xabber or yaxim to jabberd2
Hello Tomasz On 07.01.2014 00:29, Tomasz Sterna wrote: Dnia 2014-01-06, pon o godzinie 22:06 +0100, Fabian Wenk pisze: @Tomasz, could this be a "bug" or change from in jabberd 2.2.17 to 2.3.1? In 2.3.0 GnuSASL >=1.1 dependency was introduced. So could there be an incompatibility between your client and new GnuSASL? I do not think so, see below. Also since 2.3.0 CyrusSASL backend is broken. Although it is disabled by default, there are still people using it. Are you using CyrusSASL backend? No, we are using the GSASL backend config option from FreeBSD port, as the CYRUS has the remark "not supported". GnuSASL in use is and was before with jabberd 2.2.17: fabian@superman:~ $ pkg_info | grep sasl gsasl-1.8.0_2 GNU SASL Library fabian@superman:~ $ In 2.3.1 --enable-superseded and --enable-experimental defaults were changed. So if you rely on superseeded and/or experimental features, you need to enable them explicitly. Enabling superseded did help and xabber could connect again with the "use SASL authentication (recommended)" option activated. bye Fabian
Re: Roster module with custom MySQL requests
Dnia 2014-01-07, wto o godzinie 02:14 +0100, Sylvain "Gugli" Guglielmi
pisze:
> As I understand it, the
> "object-sequence" don't need to be an "UNIQUE" field. Am I right on
> that ?
object-sequence is used mainly for sorting - to keep stanza ordering,
etc.
There is no enforcement on uniqueness, but in cases when you do care on
ordering, these should be unique.
In roster table you should be fine with just incrementing ver.
BTW, you could just write your UPDATE queries setting ver with next
sequence number for the table. It will save you incrementing in code and
keep it in line with how the original module does things.
> Well, I have broken that clean separation early on. For example I
> needed [...]
Sure. In case of code tied to concrete SQL it's understandable.
I was expressing my concern on changing the generic roster module which
may store data in many formats.
> Also, with many more requests, I fear the jabberd2 load will be more
> important when I switch our prod to this plugin, and the load is
> already noticeable (15% daily peak of our server)...
My bet is that loading user data for packet delivery causes that.
There is an old item on Rob's TODO list, to have two load-user events -
one when user logs in, and other used for delivery, which loads only
necessary user data. But it is still TODO ;-)
> in my experience mallocs and frees can be long, so I try to minimize
> these calls as a rule. I assumed the same goes for MySQL requests).
One of the reasons we have memory pools in jabberd2.
--
Tomasz Sterna:(){ :|:&};:
Instant Messaging ConsultantOpen Source Developer
http://abadcafe.pl/ http://www.xiaoka.com/portfolio
Re: jabberd2 and mandatory TLS
Dnia 2014-01-07, wto o godzinie 02:13 +0100, Marco Cirillo pisze:
> Metronome closes the stream with an unsupported-version stream error
> the fact jabberd2 attempts to re-establish a stream is simply wrong.
This is a bug for sure.
There is a mechanism to mark dead servers, that should be triggered by
this error.
I created a bug: https://github.com/jabberd2/jabberd2/issues/51
> Note: jabberd2 doesn't append neither to and from or a version
> attribute on the stream header, which I suppose is the pre-1.0
> behaviour / old rfc behaviour.
Yes. jabberd2 is pretty aged software.
--
Tomasz Sterna:(){ :|:&};:
Instant Messaging ConsultantOpen Source Developer
http://abadcafe.pl/ http://www.xiaoka.com/portfolio
