Hi. How can i unsubscribe from this mailing list? Regards, MB.
El 23 ene. 2018 11:04 a. m., "Alexandre Jousset" <m...@gtmp.org> 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 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 | -- > -- -|___|--------------------------------------- -- > > >
