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      |   --
--    -|___|---------------------------------------    --


Reply via email to