Mobicents weekly meeting notes, March 2, 2011
Ivelin Ivanov
Alex, Amit, Bartek, Eduardo, Luis, Oleg, Vladimir, Ivelin
Summary:
#1 JBCP 1.2.x, 5.x, 5.1.x: JBCP 5.1 still pending one bug fix for code
freeze, JBCP 1.2.x hot patch being prepared; JBCP 5.0.1 hot patch
being prepared
#2 MSS 1.5, 2.0: new stability fixes for 1.5.x; Weld integrated in
Tomcat 7 for MSS 2.0 converged apps
#3 JSLEE 2.4: completed refactoring to allow graceful shutdown/startup
in cluster mode; preparing 2.4.CR1 for community evaluation
#4 Presence: no progress; resources tied up in JSLEE and other projects
#5 MMS scheduler roadblock: still unresolved, but latest approach
seems promising; will have conclusive answer by the end of this week
#6 SS7 progress: finalizing ISUP and other issues for Beta 7; ETA end
of the week
#7 Diameter: 1.4.0.BETA1 almost ready for release; completed unit
tests for local and cluster mode;
#8 QE update, perf regression stats: perf regression ran well for MSS
and Diameter; Failed for JSLEE; improved consistency of perf tests
Log:
-------------
[10:10] <vralev> ok let me cover 1 and 2
[10:10] <ivelin> pfff. Alex!
[10:10] <ivelin> go ahead
[10:10] <ivelin> Vladimir
[10:11] <vralev> So, JBCP 5.1 is still not frozen because there some
memory leaks werefound this weak
[10:11] <vralev> and Jean had to fix some others in the past two weeks
that were just now being verified
[10:11] == tleruitte [~Ad...@ip-94-140-160-196.reverse.destiny.be] has
joined #mobicents
[10:12] <vralev> there is another leak reported in community that is
not very criticial
[10:12] <vralev> overall there is only one leak that is somewhat
critical in MSS that better be fixed and I am doing this right now
[10:13] <vralev> so we should be able to freeze JBCP 5.1 tomorow and continue
[10:13] <vralev> in the mean time a new hotfix was deleivered earlier
this week for JBCP 5.0.1, so customers are OK and dont need to rush
for 5.1
[10:14] <vralev> that's the situation with JBCP
[10:14] <ivelin> what about 1.2.x?
[10:14] <vralev> 1.2.x has a lot of fixes accumulated, but not all of
them verified
[10:15] <vralev> in fact the criticial leak was reported on top of the
latest 1.2.x, that's how we found it and it affects JBCP 5.x as well
[10:15] <vralev> a new hotfix was requested for JBCP 1.2.x and we will
deliver it probably at end of this week
[10:16] <vralev> it will have all accumulated fixes + current leak fix
[10:16] <vralev> about #2 MSS
[10:17] <vralev> Georges is done with Weld integration on tomcat 7 MSS
2.0 for converged apps, now hs is trying to see if it can work at all
on JBoss 5
[10:17] <vralev> which would be good until we have AS7
[10:17] <ivelin> so the hot fix release will be 1.2.10.hf1?
[10:17] <vralev> he will also work on the new CDI telco framework
[10:18] <vralev> ivelin: I am not sure yet if it will be 1.2.10.hf1 or 1.2.9.hf2
[10:19] <vralev> the request for hotfix on top of previous version,
not on top of 1.2.10, but if there is too much overlap we will just
base it on 1.2.10
[10:20] <ivelin> sounds messy.
[10:20] <ivelin> 1.2.9 was already hotfixed once
[10:20] <ivelin> then there is 1.2.10
[10:20] <ivelin> and 1.2.11 in the works
[10:21] <vralev> it is messy but we keep track of it
[10:21] <vralev> if we see too much risk in merges and backports we
will use 1.2.10
[10:22] <vralev> or branch head
[10:23] <ivelin> how so you keep track what fixes went where?
[10:23] <ivelin> how do you...
[10:24] <vralev> for each 1.2.x there is branch where patches are applied
[10:24] <vralev> and hotfixes are tagged from that branch
[10:24] <vralev> so we just continue on top of the currently branched
hot fix 1 to make hot fix 2
[10:25] == tleruitte [~Ad...@ip-94-140-160-196.reverse.destiny.be] has
left #mobicents []
[10:25] <vralev> we have record of hot fix 1 in a specail tag too so
we know what's where
[10:26] <ivelin> but how do you keep track of potential merge
conflicts between all these branches?
[10:26] <vralev> yes merge conflicts are a problem, so if there is any
sign of risk we talk to them about using newer branch where it is
safer
[10:27] <ivelin> dangerous. Its 5 branches and growing.
[10:27] <ivelin> ok, let's move on
[10:27] <ivelin> #3 JSLEE
[10:28] <mart1ns> we are almost ready for release
[10:28] <mart1ns> only alex work on eclipse plugin and I'm now working
on the sip ra to plug early dialog failover
[10:29] <mart1ns> so the big reworking on how the slee starts and
shutsdown , including cluster and deployments, is now complete
[10:29] <mart1ns> I was unable to make errors in startup or shutdown,
even with servers in parallel
[10:30] <mart1ns> or starting/killing a server with the cluster in high load
[10:30] <mart1ns> so I'm confident it's good
[10:30] <mart1ns> anyway we will release as 2.4.0.CR1
[10:30] <mart1ns> to give the community some time to work with it
[10:31] <ivelin> cool. you should blog about these uses cases. Hot stuff.
[10:31] <mart1ns> y
[10:31] <mart1ns> we now have a lifecyle very close to what slee specs define
[10:31] <mart1ns> that's it in slee
[10:32] <mart1ns> presence unfortunately was unable to progress, due
to SLEE being now a couple days late
[10:32] <mart1ns> hopefully tomorrow I start another task
[10:32] <mart1ns> well, at least concrete code
[10:33] <mart1ns> I've been evaluating alternatives to jaxb
[10:33] <mart1ns> getting in touch with some API communities
[10:33] <mart1ns> but so far found nothing better
[10:33] <mart1ns> there is also people working in an specific task
[10:33] <mart1ns> hopefully they will contribute soon
[10:34] <mart1ns> if no questions then you can move on :)
[10:35] <ivelin> lets move on
[10:35] <ivelin> #5 MMS scheduler roadblock
[10:36] <oleg1_> I've completed tests with separated rx and tx job -
not bad so far
[10:37] <oleg1_> asked Vladimir to verify
[10:37] <ivelin> what is "not bad"?
[10:37] <oleg1_> by the way starting new round of tests with varying
number of jobs currently in work
[10:38] <oleg1_> "nod bad" means that estamation reached - miss rate
not more then 0.3 and with jitter < 3ms
[10:39] <oleg1_> without CPU overhead at "low" number of tasks
[10:40] <oleg1_> after tests with varying task number is to try plug
it into server
[10:40] <oleg1_> step by step test it that no problems are comming
from integration
[10:41] <ivelin> when should the tests complete?
[10:42] <oleg1_> the block for varing number of tasks - tomorrow
[10:42] <oleg1_> test during integration - when integration will be done
[10:43] <oleg1_> I must be shure that no components wich can generate
unpredicatble or unstable behaviour
[10:43] <ivelin> hopefully this is it then
[10:43] <ivelin> is there plan B?
[10:44] <oleg1_> actually no more plans... everything has been tryied
already if this method wont work then looking for partenship with
other vendors
[10:45] <ivelin> hm
[10:45] <oleg1_> started with jmf, passed through all possible thread
models, the current model is most precise already
[10:46] <ivelin> let's see how this tests work out. Would be good to
see what Vladimir finds out too with fresh view.
[10:46] <ivelin> #6 SS7 progress
[10:48] <abhayani1> ok. We have completed all pending issues for current release
[10:48] <abhayani1> currently working on documentation part
[10:48] <abhayani1> and final fixes for ISUP
[10:49] <abhayani1> unfortunately 2nd card in pune lab is not present to test
[10:50] <abhayani1> we are already 2 days behind schedule
[10:50] <abhayani1> should complete doc and pending issue before
weekend and have binary ready by weekend
[10:51] <abhayani1> Bartek anything missed?
[10:52] <baranowb> nope, thats it I think
[10:53] <abhayani1> thats all for SS7 .. questions?
[10:53] <ivelin> what's this week's release number?
[10:53] <abhayani1> Beta7
[10:54] <ivelin> #7 Diameter
[10:54] <@alexandrem> we have everything ready for the 1.4.0.BETA1
release, we have fixed all the issues assigned to it
[10:55] <@alexandrem> also we have created comprehensive junits to
test every application both in local
[10:55] <@alexandrem> and replicated mode
[10:57] <@alexandrem> but we have not released due to dependency to new cluster
[10:57] <@alexandrem> (sorry had phone call..)
[10:57] <@alexandrem> and dependency to updated RAs due to new lifecycle
[10:58] <@alexandrem> so we will release together with SLEE 2.4.0.CR1
[11:02] <ivelin> does the replication work in MSS setup?
[11:03] <@alexandrem> yes, for MSS it's similar to standalone, so it
works in the same way as we test it with JUnits
[11:03] <ivelin> is it on the roadmap to test failover of an app that
has both sip and diameter state?
[11:04] <@alexandrem> it is not on the roadmap specifically
[11:04] <baranowb> its planed, not in roadmap directly I think
[11:04] <@alexandrem> but it's what we intend to test next
[11:04] <baranowb> as an example
[11:10] <ivelin> would be good to make sure that cross protocol
failover is not adding surprises
[11:10] <ivelin> #8 QE update, perf regression stats
[11:11] <barreiro> This week I've benn changing all the perf jobs so
that there is a warm up period that it's not recorded on the test
results
[11:11] <barreiro> that makes the results much more clean, predictable
and comparable
[11:11] <ivelin> did the perf jobs run on their own?
[11:12] <barreiro> I changed the goals accordingly
[11:12] <barreiro> for MSS and diameter yes ... for SLEE there is a
problem in the release script
[11:13] <barreiro> I also ported that change to the JBCP jobs
[11:13] <ivelin> making progress
[11:14] <ivelin> did the MSS or diameter jobs discover any regression/
[11:14] <barreiro> There was also some questions about the response
time of SLEE, so I did some tests on it, increasing accuracy on what
we had
[11:15] <barreiro> there have been no performance regressions
[11:15] <barreiro> It may be interesting to share those results with
community ... what do you guys think ??? mart1ns, alexandrem ???
[11:16] <ivelin> have you been able to make progress on the reporting tool?
[11:17] <barreiro> unfortunately no. I was not expecting to make the
changes on JBCP jobs, but I was so happy with the new test procedure
that I had to do it.
[11:18] <ivelin> heh. The procedure with warm up cycle?
[11:18] <barreiro> yes.
[11:20] <ivelin> what kind of noise does it remove?
[11:22] <barreiro> in first calls there is usually a bigger response
time, due to lazy initializations I believe
[11:23] <barreiro> and when the full load was reach there was also
some instability, with more retransmissions / failed calls. This was
due to GC.
[11:24] <ivelin> makes sense
[11:24] <barreiro> Keeping the warm up phase out of the record removes
that from the test report.
[11:24] <ivelin> the science or real world simulation
[11:24] <ivelin> what else?
[11:25] <barreiro> oh, almost forgot to metion,next week I'll be off two days.
[11:25] <barreiro> I'll be lost in the woods. I'll send out a reminder
to the core.
[11:27] <ivelin> oh no :)
[11:28] <ivelin> do you know how to hunt?
[11:28] <barreiro> sometimes I watch the survival shows on discovery channel ;)
[11:30] <ivelin> lol. you should do the same with orientation. watch
on tv. or control a drone.
[11:31] <ivelin> ok team. thanks everyone.
[11:35] == oleg1_ [5ee97fd5@gateway/web/freenode/ip.94.233.127.213]
has quit [Quit: Page closed]
[11:49] == vilpan [~vil...@88-222-157-136.meganet.lt] has left #mobicents []
[14:46] == alexandrem [~unk...@bl12-92-61.dsl.telepac.pt] has quit
[Quit: This computer has gone to sleep]
[14:46] == vralev [5f2b4e98@gateway/web/freenode/ip.95.43.78.152] has
quit [Quit: Page closed]
[14:48] == alexandrem [~unk...@bl12-92-61.dsl.telepac.pt] has joined #mobicents
[14:48] == mode/#mobicents [+o alexandrem] by ChanServ
[16:35] == barreiro_ [~barr...@bl21-248-50.dsl.telepac.pt] has joined
#mobicents
[16:38] == barreiro [~barr...@bl21-251-230.dsl.telepac.pt] has quit
[Ping timeout: 240 seconds]