Hi Mik, Henning, Bastian, Norman, I tried using DBD::Sybase and it worked! Probably it was an error in the unixODBC lib or in the DBD::ODBC package. Anyway I did a first stress test today and the server managed to complete 12000 calls in 2 hours. There is a lot of improvements to make in my script and on my DB, but I think that the problem with OpenSER was solved (I hope!). I will test the server exhaustively, and when it becomes stable I will tell you what load it can handle.
For now thanks for the help! Murilo -----Original Message----- From: Mik Cheez [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 24 de setembro de 2007 18:41 To: Murilo Lacerda Yoshida Cc: users@openser.org Subject: Re: [OpenSER-Users] perl + unixODBC I connect to several remote MSSQL servers this way, yeah ;) Murilo Lacerda Yoshida wrote: > Yes, that probably is a good path ... I will test this. > > Mik, when you say you have several systems running with high loads, you > have these systems running OpenSER and MSSQL? If so it's a good thing, > it means that it works... > > Thanks, > Murilo > > > > -----Original Message----- > From: Mik Cheez [mailto:[EMAIL PROTECTED] > Sent: segunda-feira, 24 de setembro de 2007 18:17 > To: Murilo Lacerda Yoshida > Cc: users@openser.org > Subject: Re: [OpenSER-Users] perl + unixODBC > > I see now, they *are* used internally...sorry to lead you on the wrong > path. > > I've actually had much better luck using the Sybase driver (DBD::Sybase) > > with FreeTDS for MSSQL. I have several systems running with high loads > with no issues. > > mIK > > Can you send a > > Murilo Lacerda Yoshida wrote: >> Mik, >> Now I'm confused ... I saw this module AVPops and its functionality >> and I decided not to use it ... but when I did this I checked if it > was >> essential for OpenSER, and I thought it was not. >> >> I guess I was wrong then ... What value should the variables > new_code >> and rcv_info have? >> >> What sounds strange to me is that the functions >> t_should_relay_response and receive_msg (where these variables appear) >> are not used by me on the script, they are used internally by OpenSER. >> >> Thanks, >> Murilo >> >> >> >> -----Original Message----- >> From: Mik Cheez [mailto:[EMAIL PROTECTED] >> Sent: segunda-feira, 24 de setembro de 2007 16:23 >> To: Murilo Lacerda Yoshida >> Cc: users@openser.org >> Subject: Re: [OpenSER-Users] perl + unixODBC >> >> If I'm understanding the dump you've included, it looks like you're >> missing declarations for your variables "new_code" and >> "rcv_info" in avpops. >> >> They could be something like this in your OpenSER config file: >> >> avp_aliases="new_code=i:34;rcv_info=i:36" >> >> Then you can assign a value in Perl like so: >> >> OpenSER::AVP::add(34, "$new_code"); >> >> Mik >> >> >> Murilo Lacerda Yoshida wrote: >>> Hi Henning, >>> This is the coredump for the crash described: >>> >>> #0 0xb7dcd7c6 in raise () from /lib/libc.so.6 >>> #1 0xb7dcf0e1 in abort () from /lib/libc.so.6 >>> #2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6 >>> #3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6 >>> #4 0xb7e108e0 in free () from /lib/libc.so.6 >>> #5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8 >>> #6 0xb5931f2e in odbc_st_destroy () from >>> /usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so >>> #7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from >>> /usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so >>> #8 0xb5a30ac4 in XS_DBI_dispatch () from >> /usr/lib/perl5/auto/DBI/DBI.so >>> #9 0xb7c5c81b in Perl_pp_entersub () from /usr/lib/libperl.so.5.8 >>> #10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8 >>> #11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8 >>> #12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8 >>> #13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8 >>> #14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8 >>> #15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8 >>> #16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8 >>> #17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8 >>> #18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8 >>> #19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8 >>> #20 0xb7c68ce6 in Perl_sv_force_normal_flags () from >>> /usr/lib/libperl.so.5.8 >>> #21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8 >>> #22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8 >>> #23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8 >>> #24 0xb7c5af19 in Perl_runops_standard () from > /usr/lib/libperl.so.5.8 >>> #25 0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8 >>> #26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8 >>> #27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8 >>> #28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP", >>> mystr=0x0) at perlfunc.c:150 >>> #29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP", >>> foobar=0x0) at perlfunc.c:90 >>> #30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at >>> action.c:883 >>> #31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at >>> action.c:131 >>> #32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020, >>> val=0xbfb76b88) at route.c:1058 >>> #33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at >>> action.c:198 >>> #34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at >>> action.c:986 >>> #35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at >>> action.c:131 >>> #36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at >>> action.c:801 >>> #37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at >>> action.c:131 >>> #38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at >>> action.c:111 >>> #39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at >>> action.c:131 >>> #40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at >>> action.c:111 >>> #41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18, >>> new_code=Variable "new_code" is not available. >>> ) at t_reply.c:601 >>> #42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78, >> branch=0, >>> msg_status=503, cancel_bitmap=0xbfb773a0) at t_reply.c:1035 >>> #43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383 >>> #44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489 >>> #45 0x08084124 in receive_msg ( >>> buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia: > SIP/2.0/UDP >>> 192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP >>> 19---Type <return> to continue, or q <return> to quit--- >>> 2.168.3.186:5060\r\nTo: >> <sip:[EMAIL PROTECTED]>\r\nFrom: >>> <sip:115083400"..., len=334, rcv_info=Variable "rcv_info" is not >>> available. >>> ) at receive.c:195 >>> #46 0x080b534a in udp_rcv_loop () at udp_server.c:465 >>> #47 0x0807011b in main_loop () at main.c:834 >>> #48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399 >>> >>> >>> Apparently the problem is somewhere in Perl? >>> >>> Thanks, >>> Murilo >>> >>> >>> >>> -----Original Message----- >>> From: Henning Westerholt [mailto:[EMAIL PROTECTED] >>> Sent: segunda-feira, 24 de setembro de 2007 05:23 >>> To: users@openser.org >>> Cc: Murilo Lacerda Yoshida >>> Subject: Re: [OpenSER-Users] perl + unixODBC >>> >>> On Friday 21 September 2007, Murilo Lacerda Yoshida wrote: >>>> Hello all, >>>> I'm new in the list, so first of all I would like to say hi to all >>> the >>>> list and say that openSer is a fantastic product, and that the >>>> documentation available on the internet is also fantastic. >>>> [..] >>> Hello Murilo, >>> >>> nice to hear that. :-) >>> >>>> The other and main reason is that for some unknown reason the >> openSer >>>> server crashes when using perl scripts that communicate with DB in >>> high >>>> load contexts. For some reason the perl script receives a sig_segv >>>> (segmentation fault) and this signal is passed to all others threads >>> and >>>> then the openSer server dies. >>>> >>>> This error is that kind of error that is specially difficult to >> find, >>>> because there are too many different systems involded. The path from >>>> openSer to the DB would be: >>>> >>>> openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC >> -> >>>> FreeTDS -> MS SQLServer >>> Yes, there are quite a bit modules involved. >>> >>> Take a look into the core dump (set core_dump = yes) with gdb, this >>> should >>> give you further informations about the cause of the segmention > fault. >>> To get >>> a better backtrace install the debug package (debian) or compile with > >>> debugging enabled. If the error is located in openser, please post > the >>> backtrace also on the list. >>> >>> Cheers, >>> >>> Henning >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@openser.org >>> http://openser.org/cgi-bin/mailman/listinfo/users >>> >>> >> > > _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users