Re: Stepping down

[Alexander Velin]

On 2018-01-21 01:57, Tomasz Sterna wrote:

Directly related to this, I will be shutting down all my XMPP related
services - including this mailing list, as the virtual machine hosting
it is going away. It is financed up to end of February, so expect it to
go down during March 2018.


Hi,

I'd be happy to provide maillist at

https://lists.uni-sofia.bg

Maybe jabbe...@lists.uni-sofia.bg ?

regards,
--velin

Re: Stepping down

[Alexandre Jousset]

Le 21/01/2018 à 16:24, Tomasz Sterna a écrit :

W dniu nie, 21.01.2018 o godzinie 15∶01 +0100, użytkownik Alexandre
Jousset napisał:


[...]



I don't know if I'm skilled enough but instead of letting it
die, I would like to become the maintainer if nobody with better
skills wants to :-)


Judging by your contributions to jabberd2, I see no problem in passing
the project to you.


Thanks for this :-)

I suggest to, of course, give some time to other people to volunteer if 
they wish to.

Some said they could host the jabberd2.org website or the mailing list, 
and that may help another maintainer, but in the case I become the new 
maintainer I think I could do that too.

However, note that I only have access to Linux boxes, so I may need 
help from someone else about the other OS's ports. That may be a problem.


BTW I was recently doing some load test and having thought
about solving the SPOF of the router process, [...]


We already had a _lengthy_ discussion on list on my vision how to
multiply the router:
https://www.mail-archive.com/jabberd2@lists.xiaoka.com/msg01909.html

Your work still lives in:
https://github.com/jabberd2/jabberd2/tree/mesh


I know :-)

My concern is that the work I've done is complex and not thoroughly 
tested. That does not mean it should be abandoned, but maybe a shorter term 
solution could be found just to remove the SPOF (without necessarily 
implementing the whole router mesh). And as I said at that time, I'm not at all 
happy with my routing graph discovering feature I implemented.

I see 3 approaches here:
- a heartbeat / failover solution, for cases where the single router 
(which could be switched without disconnecting users) is not a bottleneck?
- a simplification of my work to get a router mesh less dynamic but easier to 
implement? I haven't thought a lot about this yet but I checked out the "mesh" 
branch again on my computer and I'm currently digging into it to see how to simplify it. 
Any advice welcome :-)
- work fast and hard to simplify / finish the mesh branch code :-)

I also experimented a "multi-router" setup, which works great, but 
needs that all the c2s's and all the sm's to be connected to all routers at the same time 
in order for them to work as expected, thus not allowing a failover setup, just a kind of 
multithread (actually multiprocess / multihost) setup.


But my latest approach was to ditch the router component in favor to
message bus (using 0MQ). See discussion at
https://gitter.im/jabberd2/jabberd2?at=56b8b4e9939ffd5d15f671e1

This is what https://github.com/jabberd2/jabberd2/commits/ashnazg
branch implemented and jabberd3 code (which was born of ashnazg branch) was 
going for.


Just a question about this, you are talking about 0MQ, but the source 
points to nanomsg...?

Anyway, I think it is a better solution indeed and it looks promising, and this 
is one of the reasons I think a shorter term / simpler solution should be found for the 
router / SPOF in j2. I mean, priority should be given to j3 (but of course with 
continuing maintaining "normally" j2).

And about j3, I'm afraid I didn't fully understood what you said, I'm 
sorry. You said in your first message that you are going away from all XMPP 
work, and that you're opening the source of j3 (and another project), but you 
only say you're stepping down from the j2 lead. Just to be clear, is it the 
same for the other projects?



The rest of this post is of about other topics I wanted to say / ask 
the list.

I started to implement a Redis storage backend based on the BDB one. It 
is still experimental but I get good performance with it, especially with 
millions of users in my tests (see below). I'd like to know if people would be 
interested in it? I made the assumption (based on some web found comparison 
pages) that BDB doesn't scale well with lot of users.

I also started to make some load tests, using a home made XMPP tester (I tried 
Tsung but I'm not at ease with it nor with Erlang to customize it) on a 
"few-nodes-setup", and I managed to connect up to 5M simultaneous users using a 
simple scenario (connect / send message randomly from time to time but not getting roster 
nor presences for the moment). About this my questions to the list are the following:
- What is your biggest known j2 installation in terms of account number 
and simultaneously connected users?
- Same question in a test environment?
- Do you know about an XMPP stress-tester (apart from Tsung) that is 
able to connect millions of users? My searches only led me to Tsung in that 
category.

Thanks,
--
--  \^/--
---/ O \-----
--   | |/ \|  Alexandre (Midnite) Jousset  |   --

Re: Stepping down

[Dan White]

List-Unsubscribe: 
List-Help: 

On 01/23/18 11:20 -0300, Marco Bertolaccini wrote:

Hi. How can i unsubscribe from this mailing list?

Regards,
MB.

Re: Stepping down

[Marco Bertolaccini]

Hi. How can i unsubscribe from this mailing list?

Regards,
MB.

El 23 ene. 2018 11:04 a. m., "Alexandre Jousset"  escribió:

> Le 21/01/2018 à 16:24, Tomasz Sterna a écrit :
>
>> W dniu nie, 21.01.2018 o godzinie 15∶01 +0100, użytkownik Alexandre
>> Jousset napisał:
>>
>> [...]
>
>>
>> I don't know if I'm skilled enough but instead of letting it
>>> die, I would like to become the maintainer if nobody with better
>>> skills wants to :-)
>>>
>>
>> Judging by your contributions to jabberd2, I see no problem in passing
>> the project to you.
>>
>
> Thanks for this :-)
>
> I suggest to, of course, give some time to other people to
> volunteer if they wish to.
>
> Some said they could host the jabberd2.org website or the mailing
> list, and that may help another maintainer, but in the case I become the
> new maintainer I think I could do that too.
>
> However, note that I only have access to Linux boxes, so I may
> need help from someone else about the other OS's ports. That may be a
> problem.
>
> BTW I was recently doing some load test and having thought
>>> about solving the SPOF of the router process, [...]
>>>
>>
>> We already had a _lengthy_ discussion on list on my vision how to
>> multiply the router:
>> https://www.mail-archive.com/jabberd2@lists.xiaoka.com/msg01909.html
>>
>> Your work still lives in:
>> https://github.com/jabberd2/jabberd2/tree/mesh
>>
>
> I know :-)
>
> My concern is that the work I've done is complex and not
> thoroughly tested. That does not mean it should be abandoned, but maybe a
> shorter term solution could be found just to remove the SPOF (without
> necessarily implementing the whole router mesh). And as I said at that
> time, I'm not at all happy with my routing graph discovering feature I
> implemented.
>
> I see 3 approaches here:
> - a heartbeat / failover solution, for cases where the single
> router (which could be switched without disconnecting users) is not a
> bottleneck?
> - a simplification of my work to get a router mesh less dynamic
> but easier to implement? I haven't thought a lot about this yet but I
> checked out the "mesh" branch again on my computer and I'm currently
> digging into it to see how to simplify it. Any advice welcome :-)
> - work fast and hard to simplify / finish the mesh branch code :-)
>
> I also experimented a "multi-router" setup, which works great, but
> needs that all the c2s's and all the sm's to be connected to all routers at
> the same time in order for them to work as expected, thus not allowing a
> failover setup, just a kind of multithread (actually multiprocess /
> multihost) setup.
>
> But my latest approach was to ditch the router component in favor to
>> message bus (using 0MQ). See discussion at
>> https://gitter.im/jabberd2/jabberd2?at=56b8b4e9939ffd5d15f671e1
>>
>> This is what https://github.com/jabberd2/jabberd2/commits/ashnazg
>> branch implemented and jabberd3 code (which was born of ashnazg branch)
>> was going for.
>>
>
> Just a question about this, you are talking about 0MQ, but the
> source points to nanomsg...?
>
> Anyway, I think it is a better solution indeed and it looks
> promising, and this is one of the reasons I think a shorter term / simpler
> solution should be found for the router / SPOF in j2. I mean, priority
> should be given to j3 (but of course with continuing maintaining "normally"
> j2).
>
> And about j3, I'm afraid I didn't fully understood what you said,
> I'm sorry. You said in your first message that you are going away from all
> XMPP work, and that you're opening the source of j3 (and another project),
> but you only say you're stepping down from the j2 lead. Just to be clear,
> is it the same for the other projects?
>
> 
>
> The rest of this post is of about other topics I wanted to say /
> ask the list.
>
> I started to implement a Redis storage backend based on the BDB
> one. It is still experimental but I get good performance with it,
> especially with millions of users in my tests (see below). I'd like to know
> if people would be interested in it? I made the assumption (based on some
> web found comparison pages) that BDB doesn't scale well with lot of users.
>
> I also started to make some load tests, using a home made XMPP
> tester (I tried Tsung but I'm not at ease with it nor with Erlang to
> customize it) on a "few-nodes-setup", and I managed to connect up to 5M
> simultaneous users using a simple scenario (connect / send message randomly
> from time to time but not getting roster nor presences for the moment).
> About this my questions to the list are the following:
> - What is your biggest known j2 installation in terms of account
> number and simultaneously connected users?
> - Same question in a test environment?
> - Do you know about