<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Ryan,<br>
<br>
Can you please open a SF bug about the db_virtual with insert
buffering, describing the setup and what's happening ( if no rows
were inserted at all, or there were rows missing, etc ) ?<br>
<br>
Also, thanks for the futex patch, we will definitely look into it.<br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a> </pre>
<br>
On 10/29/2012 10:39 PM, Ryan Bullock wrote:
<blockquote
cite="mid:CAAcj4gWwCaaE8W7J8mNcTeasO7_q6WXxXSF=X3fu8wdv9_zAZQ@mail.gmail.com"
type="cite">Hey Bogdan,<br>
<br>
I came across the insert buffer problem with db_virtual when I was
testing the patch for Bug ID# 3568579. I couldn't figure out why
insert buffering wasn't working at all. Removing db_virtual and
using straight db_mysql and buffering worked. I am actually taking
advantage that buffering doesn’t work with db_virtual for use with
the dialog module (seems to get a bit out of sync with the
database if buffering is on). <br>
<br>
I thought insert buffering not working was intentional, however
looking at the db_virtual source is *should* work. My guess would
be that the capability flags are getting a bit messed
up/overwritten somewhere. I can open a bug for this, if it should
actually be working.<br>
<br>
<br>
1&2 are things that make working in a HA/distributed
environment easier. Having a cache go down should hopefully only
cause a performance hit, not an outage :)<br>
<br>
We moved the futex patch into production recently and it seems to
be holding up thus far.<br>
<br>
Regards,<br>
<br>
Ryan<br>
<br>
<br>
<div class="gmail_quote">On Mon, Oct 29, 2012 at 3:20 AM,
Bogdan-Andrei Iancu <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:bogdan@opensips.org"
target="_blank">bogdan@opensips.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> <tt>Hi Ryan,<br>
<br>
Indeed, several SIP stacks do not properly implement
in-dialog OPTIONS - this is why we want to add re-INVITE
as this is widely supported.<br>
<br>
1) we can add that on the wish list, let's see what time
will allow to do.<br>
<br>
2) interesting idea...We need to check on connecting on
the fly - add it to the list.<br>
<br>
3) why is it not working ? could you detail the issues you
have there ?<br>
<br>
Regarding the FUTEX patch - it definitely looks really
interesting - we will do a review and upload it on SVN. <br>
<br>
Thanks and Regards,<br>
</tt>
<div class="im">
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a moz-do-not-send="true" href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
<br>
</div>
<div>
<div class="h5"> On 10/26/2012 09:01 PM, Ryan Bullock
wrote:
<blockquote type="cite">The re-Invite pinging sounds
great, so long as it is separate dlg flag from the
OPTIONs ping. I know from experience that certain
systems (Asterisk) will sometimes incorrectly respond
with a 200 OK to in-Dialog OPTIONS when the call is
actually gone. On the other hand, some equipment can't
handle re-Invites either.<br>
<br>
A few things that I have noted, and that would be nice
to see in a future release:<br>
<br>
1. Better failure handling for cachedb_*. We use
memcached and have lost a cache node before. Opensips
will just continually timeout trying to read from the
failed node. The only way to get it to stop was to
edit the configuration to remove the dead node then
restart opensips. Would be nice if this behaved
similar to db_virtual or rtpproxy in detecting
timeouts and retrying so often, as well as some mi
commands to disable a cache temporarily.<br>
<br>
2. Opensips should be able to start even if db_virtual
was not able to connect to all databases. So long as
it can connect to at least 1 it should still work. We
have had to move away from using db_vritual because of
this problem.<br>
<br>
3. Insert buffering support for db_virtual. Currently
these two things don't work together, which can make
it a bit difficult to scale out database writes.<br>
<br>
On another note, I submitted a patch for direct futex
support under linux for locking. It has shown good
promise in my testing and I am wondering if there is
any interest in trying to get it included for 1.9?<br>
<br>
Regards,<br>
<br>
Ryan<br>
<br>
<br>
<div class="gmail_quote">On Fri, Oct 26, 2012 at 8:20
AM, Bogdan-Andrei Iancu <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bogdan@opensips.org"
target="_blank">bogdan@opensips.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt
0pt 0pt 0.8ex; border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">Hi all,<br>
<br>
I would like to start a discussion about the next
OpenSIPS major release - and in this discussion
anyone is welcomed with options, ideas, critics
and other. Your feedback is important to drive the
project into a direction that reflects the user's
needs!.<br>
<br>
So, I will here the starting points, for both
release planing and release content.<br>
<br>
<br>
Content<br>
-------<br>
What was done:<br>
<a moz-do-not-send="true"
href="http://www.opensips.org/Main/Ver190#toc2"
target="_blank">http://www.opensips.org/Main/Ver190#toc2</a><br>
What is planned:<br>
<a moz-do-not-send="true"
href="http://www.opensips.org/Main/Ver190#toc9"
target="_blank">http://www.opensips.org/Main/Ver190#toc9</a><br>
Planned items have priorities (for being
addressed); it is a must to have all items done
for the next release, as we need to fit into a
time frame. Whatever is not done, will be left for
the next release (1.10)<br>
<br>
<br>
Planing<br>
-------<br>
Release candidate:<br>
second half of January 2012, depending on the
progress with the items to be done.<br>
Testing phase:<br>
1 month allocated (it may be extended if
critical problems show up)<br>
Stable release:<br>
second half of February (after the testing
phase is done).<br>
<br>
<br>
Once again, your feedback on these matters is
important to us.<br>
<br>
<br>
Best regards,<span><font color="#888888"><br>
<br>
-- <br>
Bogdan-Andrei Iancu<br>
OpenSIPS Founder and Developer<br>
<a moz-do-not-send="true"
href="http://www.opensips-solutions.com"
target="_blank">http://www.opensips-solutions.com</a><br>
<br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Devel@lists.opensips.org"
target="_blank">Devel@lists.opensips.org</a><br>
<a moz-do-not-send="true"
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel"
target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a><br>
</font></span></blockquote>
</div>
<br>
<pre><fieldset></fieldset>
_______________________________________________
Devel mailing list
<a moz-do-not-send="true" href="mailto:Devel@lists.opensips.org" target="_blank">Devel@lists.opensips.org</a>
<a moz-do-not-send="true" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a>
</pre>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Devel@lists.opensips.org">Devel@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a>
</pre>
</blockquote>
</body>
</html>