Мobicents weekly meeting notes, November 4, 2009
Ivelin Ivanov
Alex, Amit, Bartek, Eduardo, Jean, Luis, Pavel, Oleg, Vladimir, Ivelin
Summary:
#1 MMS 2.0: Beta release on track for next week; video support
implemented, adding examples; SS7 road block with pure Java, resorting
to JNI
#2 MSS 1.1: HA performance issues, replication via JBCache eats up
too much memory, profiling and working with JBCache team to resolve;
more use cases covered by SIP LB
#3 IBPX 1.x: more downloads of the released version, not much
feedback; working with Weld and port to JB5
#4 Diameter 1.x: Sh and Ro RAs remain to be ported to JSLEE 2.0; HSS
project will kick-off next week;
#5 JSLEE 2.0: code freeze today; finishing off examples and
preparing for QE hand-over; release on track for release next week;
#6 Productization JBCP 1.2.2, Roadmap docs: JSLEE 1.2.7 and MSS 1.1
pending for the JBCP 1.2.2 release; Automated Release notes prototyped
with new GCode Issues API; Auto generated Roadmap documents next
#7 QE: prepared hiring plan for next year; returning to SIP HA test
framework this week
Log:
<ivelin> hi team
<ivelin> what time is it for everyone?
<ivelin> its 10am here, the time shifted by one hour over the weekend
<deruelle> ok we are in sync then
<ivelin> anyone having trouble joining here?
<ivelin> don't see Pavel
<ivelin> ok, let's make up the agenda
<ivelin> #1 MMS 2.0
<ivelin> #2 MSS 1.1
<ivelin> #3 IBPX 1.x
<ivelin> #4 Diameter 1.x
<ivelin> #5 JSLEE 2.0
<ivelin> #6 Productization JBCP 1.2.2, Roadmap docs
<ivelin> what else?
<mart1ns> QA?
<ivelin> oops
<ivelin> #7 QE
<ivelin> ok, lets' go
<oleg> ok
<oleg> SS7 - working on I/O. Now considering a way with native code
<oleg> Video - cleaning code and creating example
<oleg> next week we will test examples and prepare release
<oleg> mtp is now only blocking
<oleg> but I think we can resolve IO problem at least using JNI
<oleg> the next problem is SCTP
<oleg> Open JDK implements it but in fact only unix supports SCTP
<oleg> so we should restrict SS7 ussage for unix only
<oleg> that's it for mms
<ivelin> that's pretty limiting
* brainslog (n=bs...@85.138.27.15) has joined #mobicents
<ivelin> does it make sense to try the SIGTRAN route?
<oleg> yes, but I do not think that this is significant
* brainslog is now known as alexandrem
* slegrik (n=sle...@186.136.broadband9.iol.cz) has joined #mobicents
<oleg> SIGTRAN == SCTP
<alexandrem> hi. sorry I'm late.
<slegrik> Hi guys, sorry being late
<oleg> in any cases SS7 will be restricted for unix only
<oleg> but as I said it is not so dangerous because at operator side
unix always is used
<ivelin> hm, but then you have multipel versions and vendors of unix
<abhayani> I think for now we can stick to RHEL and Solaris
<ivelin> SIGTRAN is ONLY SCTP? No UDP or TCP option?
<abhayani> that too specific versions
<oleg> I agree with Amit
<ivelin> which versions of RHEL?
<vralev> there is still a chance you an keep the IO in java, but
implement the pre-IO initiatiozation in something like perl
<oleg> yes, sigtran uses SCTP only
<oleg> what are the benefits of such way, Vlad?
<abhayani> RHEL 5 is latest and we can give it a try
<vralev> oleg, both perl and Java are platform-independent
<vralev> so need to worry abt 32bit/64bit/solaris/etc
<oleg> I think it will be very difficult to maintane such system
<oleg> with perl and java
<vralev> not at all
<oleg> anyway we have restriction from sigtran
<baranowb> vlad got any examples ?
<vralev> bart, what you need is ioctl and fcntly unix API calls that
are not avaialble in java, both are available in perl, full of
examples in the net how to use these
<vralev> fcntl
<baranowb> k
<ivelin> sounds reasonable, especially if they have been around in
perl for some time
<oleg> perl should be installed on OS?
<vralev> ivelin, these APIs are kernel serivces, they go directly to
drivers etc, perl just calls the kernel code, any C API is availalbe
from perl
<oleg> and how to access perl code from Java?
<oleg> Vlad, so we will have additional intermediation C - Perl - Java
<oleg> ?
<baranowb> there should be examples as vlad said
<vralev> oleg, no need to access perl code from java - you just
execute the device initialization code there
<oleg> I do not think that this is a good way
<ivelin> I think Vladimir's point is that perl is always installed on unix
<abhayani> IMO, we should let the native code do all MTP2 and MTP3
work and directly give higher level comands to JAVA stack via SCTP
<ivelin> and these perl functions are available out of the box across
many versions and vendors
<abhayani> no need to access the native code via Java
<oleg> Amit, how do you imagine this/
<vralev> note that I am talking about the case assuming all that is
needed for IO to work is the initialization routine, if the IO really
can't be dont in java, perl doesnt make sense indeed, but otherwise it
would be good and portable
<abhayani> for example let MTP2 and MTP3 be in C
<abhayani> and MTP3 will open SCTP socket and transfer the stream to
MTP3UA which we implement in Java and listening on SCTP Socket
<vralev> we do something like this in the IzPack installer - generate
shell and perl scripts for unix to do native stuff
<oleg> Vlad, we need read and write, device is intialized
<baranowb> not sure if there is Mtp3 implementation freely available :)
<abhayani> chan_ss7 has basic I believe
<oleg> Amit, who will write SCTP on see?
<vralev> oleg, if you need read and write then perl cant help you
<oleg> C
<oleg> Bartek, did you try to return pointer to the begining with
RandomAccessFile?
<abhayani> assuming that C impl of SCTP available
<vralev> oleg, but it seems like read and write are the same in C and
java, only ioctl and fcntl are different
<baranowb> y, iirc I did, but Im double checking two things
<baranowb> right now
<oleg> Vlad, I think that we can use Java only but I do not know
exavtly where is a problem. So we are considering JNI as way to make
it faster
<vralev> ok then, jnI is not so bad as long as you dont have
non-kernel dependencies
<oleg> pipes only
<ivelin> it is possible that you will figure out the java issues once
you start digging in the jni code
<ivelin> I've had a similar case in teh past with Java graphics performance
<ivelin> looking at JNI forced me to debug the JDK C source code and
figured out the issue
<ivelin> so, release is due next week, with or without SS7, right?
<oleg> we want to have ss7
<oleg> we can decide in Monday what we actualy have with ss7
<ivelin> ok
<ivelin> other points on MMS?
<oleg> and if it is possible to be ready with i/o on next week we
will try to complete
<oleg> no, that's it
<ivelin> ok, thank you
<ivelin> #2 MSS 1.1
<deruelle> more bugs have been fixed
<deruelle> and we reduced the network traffic
<deruelle> for MSS HA
<deruelle> and jain sip HA
<deruelle> to a bare minimum
<deruelle> I pinged bela
<deruelle> to get some advice on the testing part
<deruelle> and he advised to test on a single machine
<deruelle> with 2 jboss instances
<deruelle> syaing it would be similar to a network
<deruelle> so I tried
<deruelle> and achieved 150 cps
<deruelle> in HA mode
<deruelle> with 2 Gb of heap
<deruelle> but the memory was not enough
<deruelle> so I will try to repdouce on the lab
<ivelin> wow
<ivelin> 2GB not enough?
<deruelle> nope
<deruelle> mem was growing
<ivelin> what kind of state is stored?
<ivelin> more than 1K per call?
<vralev> deruelle, actually this is already setup in the lab
<deruelle> in the cache ?
<ivelin> makes no sense
<ivelin> ouch
<deruelle> vralev, ok let's try tomorrow
<deruelle> yes we are at 10K per call I would say
<deruelle> I mean messages exchanged
<deruelle> in the cache we store about
<deruelle> 5K I would say
<deruelle> actually with one node and no replication I can handle
<deruelle> 250 cps with 2 Gb
<ivelin> that's still a lot of memory for so little state per call
<vralev> java serialization is not very efficient
<ivelin> bummer. What is Bryan saying about it/
<deruelle> didn't pinged him yet
<vralev> for every small string it stores the type like
"java.lang.Integer" in plain text
<vralev> this comes from the serialization itself, not from jgroups or cache...
<deruelle> we could try to use another serialization mechanism
<mart1ns> if you are using 64 bits jdk then 2GB is nothing
<oleg> java allows to custom package
<deruelle> http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
<ivelin> what do you mean 2GB is nothing?
<deruelle> no I'm using 32 bits
<deruelle> mart1ns, we have some complaints that we are using more
mem in non HA than competitors
<ivelin> 2GB is way too much
<mart1ns> jsip eats a lot of mem
<mart1ns> once the call rate goes up
<mart1ns> ivelin, slee 2.x in 64bits JDK
<mart1ns> can't go over 200cps with 2GB
<ivelin> 1KB X 250 calls = 250K that's 10,000 times less than 2GB!!!
<mart1ns> at 450 cps it is taking 65% of 8GB
<mart1ns> 64 bits rulessss
<vralev> martins, that's probably a GC issue
<mart1ns> prob is that there is not an option, usually you can't have
more than 2GB of 32 bits heap
<deruelle> ivelin you account only for the data i the cache there
<deruelle> which is more like 5K
<deruelle> there is also all the other in memory data
<mart1ns> vralev, 64 bits consumes around 80% more than 32 bits
<deruelle> which is much bigger than that
<deruelle> we don't replicate much and we recreate a lot if there is a failover
<deruelle> to avoid transmitting too much over the wire
<mart1ns> deruelle, are those imporvements only at MSS or jain sip ha
for jboss 4?
<deruelle> MSS, jian sip ha core and jain sip ha jboss 4
<deruelle> improvements all the way through
<mart1ns> what is the work needed to extend to jain sip ha jboss 5
<deruelle> not much
<deruelle> I will try to upgrade it
<ivelin> so whats the plan for 1.1
<deruelle> one of the SA on the field has reported some leak
<deruelle> on MSS
<deruelle> with B2BUA
<deruelle> I'm profiling now
<deruelle> and it seems in some error cases, jain sip might be leaking
<deruelle> we have a few more issues to fix
<deruelle> I'm envisionning a release handed to QA in 1 week if
nothing new pops up
<mart1ns> there is too much state in the stack
<deruelle> mart1ns, that's possible indeed
<ivelin> its good the issues are coming from the field
<mart1ns> too many edge cases with totally different behavior there,
very easy to make mistakes
<ivelin> what else on MSS
<deruelle> I'm doing a JUG next week in Stuttgart
<deruelle> will be traveling mon,day and tuesday
<deruelle> it's about it
<vralev> let me update you on the SIP LB here
<deruelle> vlad may update on LB though
<ivelin> ок
<deruelle> oh :-)
<vralev> There is a new revision of the docs
http://docs.google.com/present/view?id=dc5jp5vx_89cxdvtxcm
<vralev> what changed from last week, is that it supports again two
SIP ports and configurable transport (it supports one SIP port as
well)
<vralev> I found a case where one SIP port would not be good and for
that case we need two ports like before
<vralev> this is when you have a non-record routing proxy in the SIP
app server - subsequent requests would be lost, for all other cases
one SIP port is enough
<vralev> so that's it for the SIP LB, it just covers more cases
<vralev> next?
<deruelle> that's you again ;-)
<vralev> oh # IPBX
<vralev> #3 IPBX
<vralev> well, still no feedback, and still good traffic
<vralev> on the last release
<vralev> so I am leaving it like that for a while
<vralev> I am playing with the new Weld to port it to AS 5
<ivelin> download stats yet?
<vralev> for now it seems most of the UI cant ported easily to Weld,
but there is a small problem with the SIP part
<vralev> no download stats, just page hit counts
<ivelin> what's the number?
<deruelle> what is the problem ?
<vralev> number for the last week is about 30-50 per day
<vralev> but the prev week it was in the thousands
<ivelin> not bad
<ivelin> that's all?
<vralev> yes
<mart1ns> tinoni
<deruelle> :-)
<mart1ns> ivelin ?
<deruelle> #4 Diameter 1.x
<ivelin> go
<ivelin> Alex?
<mart1ns> brb
<mart1ns> need some coffee
<alexandrem> yes
<alexandrem> no big update on diameter
<alexandrem> docs are fixed, cca for 2.x is committed,, Rf
semi-ported, no further progress
<baranowb> only 1 or 2 issues reported against last release
<alexandrem> we should start HSS next week, after closing 2.x (done)
and 1.2.7 issues
<ivelin> 2.x JSLEE or Diameter?
<alexandrem> yes.. some download # on sourceforge have appeared, ~60
download for 1.1.0.GA
<alexandrem> JSLEE
<ivelin> all Diameter RAs for JSLEE 2.0 are done?
<alexandrem> Sh-Server and Ro missing
<ivelin> when do you expect to finish them?
<alexandrem> have been doing them when there's no other issue with
priority, but been taking 1~2 days for each
<alexandrem> since we are taking the chance to align all the RAs with
the same structure
<ivelin> what else is a priority now?
<alexandrem> regarding diameter, HSS prototype and WebService support
are the most prioritary issues, we should start them after SLEE's are
released
<alexandrem> that's it, if no further questions :)
<mart1ns> #JSLEE ?
* abhayani has quit (Read error: 110 (Connection timed out))
<ivelin> so right now the RAs are priority, right?
<ivelin> for JSLEE 2.0 or you're also helping with other JSLEE 2.0 issues
<ivelin> I'm confused as to what the priorities are exactly
<mart1ns> he has to checkin the jopr console for slee 2
<mart1ns> those RAs are not priority right now for slee 2 beta2
<alexandrem> ivelin: right now the priorities are for JAIN SLEE...
both 2.x and 1.x.y, to close all the issues. I've been migrating in
the meantime
<ivelin> ok, I see
<alexandrem> we should be done with them this week, then it will be
full time on diameter
<ivelin> what's Bartek working on?
<baranowb> for 2x code frezze is today or tomorrow
<mart1ns> today
<baranowb> worked with jared and tom on docs and examples
<ivelin> Bartek, what are you working on for JSLEE 2.0 or Diameter?
<baranowb> for diameter only docs and examples
<baranowb> rest is slee and mms
<baranowb> all my jslee 2x issues pending review now iirc, so I will
either shift more to diameter or 1.2.7
<slegrik> after releasing Slee 2.0. BETA2,we are going to close all
Slee 1.2.7 issues ? right ? what are the dates estimates ?
<ivelin> what is 1.2.7?
<baranowb> jslee branch ?
<slegrik> ivelin: Slee 1.2.7
<ivelin> lets go to jslee then
<ivelin> #5 JSLEE 2.0
<mart1ns> slegrik, yes, and fast, should be released till next wednesday
<mart1ns> ok
<mart1ns> regarding slee 2.0
<slegrik> mart1ns,ok
<mart1ns> code freeze is iminent, alex has to checkin jopr console,
I'm reviewing 2 patches from bartosz and oleg is testing/fixing smpp
ra
<mart1ns> release script is ready and tested
<ivelin> nice
<mart1ns> sip, xmpp, mgcp, diameter base, diameter sh client, smpp,
http client and http servlet
<mart1ns> the RAs going in this release
<mart1ns> we already have the examples for sip, xmpp, http servlet,
http client, mgcp
<mart1ns> btu we will release only the "usual" ones from 1.2.x, gtalk
bot, sip wake up and sip services
<alexandrem> mart1ns: want to include diameter examples too?
<mart1ns> I already tested those examples and seem fine, after code freeze
<mart1ns> final tests will be done
<mart1ns> alexandrem, no
<mart1ns> you can commit them anytime
<alexandrem> okie :)
<mart1ns> but for the release only those 3 will be bundled, to avoid
longer tests
<alexandrem> ok.. it would overlap too much on diameter release contents too :)
<mart1ns> I will try to setup a community web session regarding beta2 features
<mart1ns> since documentation is null, I think this is pretty important
<mart1ns> specially around clustering
<mart1ns> and also to get some feedback on what else should we
provide in next releases
<mart1ns> which concern is stability and container and sip clustering
improvements
<slegrik> martins, if you expect release of Slee 2.x by next
Wednesday, what are the estimates for Slee 1.2.7 ?
<mart1ns> 1.2.7 next wednesday
<slegrik> mart1ns, oh, ok I got it
<mart1ns> 2.0 should be out afetr about one day of final tests
<mart1ns> everything is more or less tested, just would like to get
feedback from luis too
<ivelin> good. Can't wait to see 2.0 out the door
* abhayani (n=abha...@122.169.35.5) has joined #mobicents
<ivelin> next?
<ivelin> #6 Productization JBCP 1.2.2, Roadmap docs
<slegrik> regarding JBCP 1.2.2 update: we are missing Slee 1.2.7 and
Sip Servlets 1.1 modules, need to wait for this ones.
<slegrik> I have updated productization pages with the approach of
announcing product releases to marketing & sales team (as spoken with
Rob).
<slegrik> Updated jbcp/mobicents-all release scripts for jbcp 1.2.2,
there was an issue with docs.
<slegrik> Worked on gcode issue tracker API + Prototyping the example
which is able to retrieve the list of the issues for the release
notes.
<slegrik> Working on design of roadmap creation/generation via gcode
API. Posted approach about managing issues to be able to automaticaly
generate roadmap from them.
<slegrik> Posted schedule for JBCP2 to jbcp-dev and awaiting answers
- regarding this one I will need your responces please !
<mart1ns> slegrik, regarding your email, 2.0 GA is still scheduled
for end of the year, we have been one month late but I think 2 months
are enough to make it stable as a rock
<slegrik> mart1ns, great
<mart1ns> the hard times are fading away
<slegrik> how about others ?
<mart1ns> also, the maven template project
<slegrik> Jean ? MSS ?
<ivelin> ok, will take a look at the jbcp2 message
<mart1ns> is applied in sip presence
<mart1ns> docs
<mart1ns> I updated the issue
<slegrik> well, you can update offline = I do not want to bother now
<deruelle> slegrik, for now ok as well
<slegrik> Anyway, till jbcp 1.2.2 moduleas are available I will focus
on the Roadmap generation issue
<mart1ns> http://code.google.com/p/mobicents/issues/detail?id=904
<ivelin> good, its a frequently requested feature
<ivelin> not feauture, but something prospects ask about
<ivelin> and the spreadsheet is starting to look horribly out of date again
<ivelin> next?
<ivelin> #7 QE
<slegrik> ivelin, spreadsheet is really terrible, I am looking
forward we will have uptodate and consistent roadmap
<barreiro> on my side, I've been deeling mostly with the Mobicents QA
plan for FY11
<mart1ns> slegrik, ideally the roadmap would be updated
automatically also from fetching new issues from gcode :p
<slegrik> mart1ns, this is the plan - for sure !
<barreiro> being with no VPN access didn't help, I was unable to do
tasks more important. That is fixed now.
<deruelle> I ve got to go
<ivelin> thanks Jean
<barreiro> Also, I've been preparing for presenting Mobicents to
Jboss QA folks ... after some delays, meeting will take place
tomorrow,
<slegrik> deruelle, same here in 5 minutes - kids going to have
another bathroom battle :)
<ivelin> :)
<barreiro> Other than that, I'll be resuming the work on MSS HA right away.
<ivelin> how is the hiring plan coming together?
<barreiro> I talked with Michael and he said that we have a good
plan, but in the end its not his decision. Anyway, things look good.
<ivelin> ok, so planning is done?
<barreiro> it's not finished yet. I've almost everything that is
needed for one JBCP release in place. Now I need to put that in a
calendar, and add resources for the project releases as well.
<slegrik> bye guys, I going to play Neptunus (Poseidon) in our
bathroom - will read offline
<ivelin> good luck, Pavel
<ivelin> don't let them sink you
<ivelin> Luis, try to wrap up this planning. Its can take forever if
you try to make it perfect. There is no need for that.
<barreiro> I know that. I discussed with Michael the abstraction
level it should have and the assumptions that we are making.
<ivelin> ok. Its already taking a week, that's why I'm getting a
little concerned.
<barreiro> As I said, I give more attention to it because I didn't
had VPN to work on other things.
<ivelin> got it
<ivelin> is that it for QE?
<barreiro> yes, that's all for now.
<ivelin> ok, thanks
<ivelin> anything we missed?
<ivelin> ok, that's all then
<ivelin> thanks everyone
* barreiro has quit ("Leaving")
* abhayani has quit ("Leaving")