Vinay S | 1 Dec 2011 03:23
Picon

Re: Possible race condition in mod_muc? (multiple ejabberd nodes)

Hi guys,

Just wanted to check if anyone got a chance to look at this.

Thanks,
-Gagan

On Tue, Nov 22, 2011 at 1:09 AM, Talk Erlang <talkerlang <at> gmail.com> wrote:
Hello everyone,

I have a vanilla distributed erlang environment with two ejabberd nodes(I guess there could be more but assuming two for simplicity), with Mnesia replication on both.
I think the following piece of code can lead to a race condition if two ejabberd nodes are started at the same time:

load_permanent_rooms(Host, ServerHost, Access, HistorySize, RoomShaper) ->
    case catch mnesia:dirty_select(
                 muc_room, [{#muc_room{name_host = {'_', Host}, _ = '_'},
                             [],
                             ['$_']}]) of
        {'EXIT', Reason} ->
            ?ERROR_MSG("~p", [Reason]),
            ok;
        Rs ->
            lists:foreach(
              fun(R) ->
                      {Room, Host} = R#muc_room.name_host,
                      case mnesia:dirty_read(muc_online_room, {Room, Host}) of
                          [] ->
                              {ok, Pid} = mod_muc_room:start(
                                            Host,
                                            ServerHost,
                                            Access,
                                            Room,
                                            HistorySize,
                                            RoomShaper,
                                            R#muc_room.opts),
                              register_room(Host, Room, Pid);


If two nodes start at the same time, they both will probably execute the same code, i.e. read from Mnesia(muc_room, which is a persistent room table) at the same time, and there is a possibility that if the table is empty, might even try to spawn the same mod_muc_room(s) processes.

Should it not be a protected/locked read & write? I imagine the sequence should be somewhat like:
Lock DB --> Read --> Write(if table does not exist) --> Unclock DB.

Please correct me if I'm wrong.


Thanks a lot!

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Rick Blair | 3 Dec 2011 01:51
Picon

s2s over high latenency low bandwidth link

I need to establish s2s connection between 2 ejabberd servers over a slow link.  Ping times in tens of
seconds.  Is this possible?  I have s2s working well in all other cases, however between these servers I get
connection and retry connection timeouts.  Is there a way to set the timeout values.

Thanks

Rick

--

-- 
Tìoraidh!

Rick Blair
rickblair <at> mac.com
Peter Vereshagin | 3 Dec 2011 02:39
X-Face
Favicon
Gravatar

latest ejabberd and erlang package compatible with icq transport?

Hello.

It seems ejabberd isn't compatible with icq transport e. g. pyicq-t, anymore.
Can anyone please suggest me the latest ejabberd and an erlang package
versions known to work with icq transport for me to downgrade?

Thank you.

--
Peter Vereshagin <peter <at> vereshagin.org> (http://vereshagin.org) pgp: A0E26627 
Badlop | 3 Dec 2011 15:49
Picon

Re: s2s over high latenency low bandwidth link

2011/12/3 Rick Blair <rickblair <at> mac.com>:
> I need to establish s2s connection between 2 ejabberd servers over a slow link.  Ping times in tens of
seconds.  Is this possible?  I have s2s working well in all other cases, however between these servers I
get connection and retry connection timeouts.  Is there a way to set the timeout values.

There isn't any option for that. But if you can recompile an erlang
source file, you can try changing those hardcoded timeouts (in
milliseconds) in ejabberd_s2s_out.erl :

-define(FSMTIMEOUT, 30000).
-define(TCP_SEND_TIMEOUT, 15000).

---
Badlop
ProcessOne
_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
viq | 5 Dec 2011 23:58
Picon
Gravatar

Re: latest ejabberd and erlang package compatible with icq transport?

On Sat, Dec 3, 2011 at 2:39 AM, Peter Vereshagin <peter <at> vereshagin.org> wrote:
> Hello.
>
> It seems ejabberd isn't compatible with icq transport e. g. pyicq-t, anymore.
> Can anyone please suggest me the latest ejabberd and an erlang package
> versions known to work with icq transport for me to downgrade?

How about http://spectrum.im ?

> Thank you.
>
> --
> Peter Vereshagin <peter <at> vereshagin.org> (http://vereshagin.org) pgp: A0E26627
> _______________________________________________
> ejabberd mailing list
> ejabberd <at> jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd

--

-- 
viq
Matthias Rieber | 6 Dec 2011 01:27

Pubsub since version 2.1.6

Hello,

I've some problems with pubsub since version 2.1.6, to be exact, 
reverting f0a848ef45b8be023e757483a7d04a5b8b018f12 seems to fix it. At 
least a bit. I can see my own published activity/mood and contacts that 
are online during mood/activity changes, can see it to. With any version 
after that, I can't see my activity/mood nor anyone else.

When I publish my activity with a server that seems to work, I 
send/receive the following stanzas:

<!-- Out -->
<iq xmlns="jabber:client" type="set" id="257">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="http://jabber.org/protocol/activity">
<item id="0">
<activity xmlns="http://jabber.org/protocol/activity">
<inactive>
<other />
</inactive>
</activity>
</item>
</publish>
</pubsub>
</iq>

<!-- In -->
<iq from='sezuan <at> jabber.ccc.de' to='sezuan <at> jabber.ccc.de/Gajim' id='257' 
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/activity'>
<item id='0'/>
</publish>
</pubsub>
</iq>

<!-- In -->
<message from='sezuan <at> jabber.ccc.de' to='sezuan <at> jabber.ccc.de/Gajim' 
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/activity'>
<item id='0'>
<activity xmlns='http://jabber.org/protocol/activity'>
<inactive>
<other/>
</inactive>
</activity>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='replyto' jid='sezuan <at> jabber.ccc.de/Gajim'/>
</addresses>
</message>

<iq> request and response *and* the message event.

With my server:

<!-- Out -->
<iq xmlns="jabber:client" type="set" id="321">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="http://jabber.org/protocol/activity">
<item id="0">
<activity xmlns="http://jabber.org/protocol/activity">
<inactive>
<other />
</inactive>
</activity>
</item>
</publish>
</pubsub>
</iq>

<!-- In -->
<iq from='matthias <at> sucksass.de' to='matthias <at> sucksass.de/Home' id='321' 
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/activity'>
<item id='0'/>
</publish>
</pubsub>
</iq>

I don't receive any messages with the activity. Is that correct? I tried 
this with a very clean configuration, tried version v2.1.9 and 2.1.x 
(both from git). The relevant configuration snippet:

   {mod_caps,     []},
   {mod_pubsub,   [
                   {access_createnode, pubsub_createnode},
                   %%{ignore_pep_from_offline, true}, % reduces resource 
comsumption, but XEP incompliant
                   {ignore_pep_from_offline, false},  % XEP compliant, 
but increases resource comsumption
                   {last_item_cache, true},
                   {plugins, ["flat", "hometree", "pep"]}  % pep 
requires mod_caps
                  ]},

What I'm doing wrog?

regards,
matthias
Michael | 6 Dec 2011 12:15
Picon
Favicon

Re: about fallback

On 27.04.2011 03:51, sergio wrote:
> On 04/27/2011 05:41 AM, Evgeniy Khramtsov wrote:
>> Probably, there is a problem with gmail server software, no?
> Yes! But how to verify this?
> 
> For example there was a similar problem with jabberd14. The solution was
> to add _jabber srv record. (As I understand jabberd14 doesn't look at
> _xmpp-server, but on _jabber)
> 
> Looks like google even doesn't try to communicate with slave.
Are there any updates on the topic?
We are currently observing the same problem over here.

I(<0.475.0>:ejabberd_s2s_out:353) : Closing s2s connection: our-domain
-> gmail.com (invalid dialback key)

and

I(<0.1469.0>:ejabberd_s2s_out:417) : wait for validation: our-domain ->
gmail.com (closed)

This is our dns setup (master is down)

_xmpp-client._tcp.jabber IN     SRV     11 0 5222 slave
_xmpp-client._tcp.jabber IN     SRV     5  0 5222 master
_xmpp-server._tcp.jabber IN     SRV     11 0 5269 slave
_xmpp-server._tcp.jabber IN     SRV     5  0 5269 master
; legacy support
_jabber._tcp.jabber      IN     SRV     11 0 5269 slave
_jabber._tcp.jabber      IN     SRV     5  0 5269 master

Is there anything wrong? Anything weird that google might choke on?

Michael
Matthias Rieber | 7 Dec 2011 00:09

Re: Pubsub since version 2.1.6

Hi,

Am 06.12.2011 01:27, schrieb Matthias Rieber:
> Hello,
>
> I've some problems with pubsub since version 2.1.6, to be exact, 
> reverting f0a848ef45b8be023e757483a7d04a5b8b018f12 seems to fix it. At 
> least a bit. I can see my own published activity/mood and contacts 
> that are online during mood/activity changes, can see it to. With any 
> version after that, I can't see my activity/mood nor anyone else.

after some more tests I recovered the old (maybe wrong?) behaviour:

Reverting f0a848ef45b8be023e757483a7d04a5b8b018f12 - EJAB-1340
fixes the cross domain sending/re-sending problems.

Reverting 8faafc5b0d30e587e842bf3b2ada6b33f89e60bd - EJAB-1456
sends a changed mood/activity back to me, like others servers.

According to the bug description it seems that this is related to the 
caps that the clients send to server, but as far as I can judge this, 
they are correct, since they contain:

<feature var="http://jabber.org/protocol/mood" />
<feature var="http://jabber.org/protocol/activity" />
<feature var="http://jabber.org/protocol/mood+notify" />
<feature var="http://jabber.org/protocol/activity+notify" />
<feature var="http://jabber.org/protocol/tune+notify" />
<feature var="http://jabber.org/protocol/nick+notify" />
<feature var="http://jabber.org/protocol/geoloc+notify" />

regards,
Matthias
sergio | 7 Dec 2011 08:46
Picon

Re: about fallback

On 12/06/2011 03:15 PM, Michael wrote:

> Are there any updates on the topic?
Unfortunately no. I think, that operators <at> xmpp.org list is more suitable
for discussing such problems, but it also didn't help.

> Is there anything wrong? Anything weird that google might choke on?
I don't see anything wrong.

--

-- 
sergio.
Matthias Rieber | 7 Dec 2011 21:27

Re: Pubsub since version 2.1.6

Hi,

reported: EJAB-1516

Regards,
Matthias

Gmane