[freeswitch-dev] in memory sqlite
Hello, Does FS support use of sqlite3_open(":memory:", ppDb) so that database is created purely in memory? Thank you Paulo
I will try to enable such feature in core.db ( I want to use just RAM core.db and to disable all other databases) If I use FS exclusively as a SIP gateway ( no registrar ) I think I can "disable" the use of such sofia tables (Does it make sense? ) : .tables sip_authentication sip_shared_appearance_dialogs sip_dialogs sip_shared_appearance_subscriptions sip_presence sip_subscriptions sip_registrations Thank you Paulo On Mon, Feb 15, 2010 at 6:22 PM, Michael Jerris <mike@jerris.com> wrote:
no
Mike
On Feb 15, 2010, at 12:35 PM, Paulo Vicentini wrote:
Hello, Does FS support use of sqlite3_open(":memory:", ppDb) so that database is created purely in memory?
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Use a ramdisk. The core will open the db multiple times so you would end up with many instances not linked to each other. If sofia uses it, it needs it, or else it would've been an optional configuration option. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 15-Feb-10, at 4:41 PM, Paulo Vicentini wrote:
I will try to enable such feature in core.db ( I want to use just RAM core.db and to disable all other databases) If I use FS exclusively as a SIP gateway ( no registrar ) I think I can "disable" the use of such sofia tables (Does it make sense? ) :
.tables sip_authentication sip_shared_appearance_dialogs sip_dialogs sip_shared_appearance_subscriptions sip_presence sip_subscriptions sip_registrations
Thank you Paulo
On Mon, Feb 15, 2010 at 6:22 PM, Michael Jerris <mike@jerris.com> wrote: no
Mike
On Feb 15, 2010, at 12:35 PM, Paulo Vicentini wrote:
Hello, Does FS support use of sqlite3_open(":memory:", ppDb) so that database is created purely in memory?
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
How hard are you hitting this box to kill it because your data base ? What distro are you on? Some versions of the linux kernel slow SQLITE down by 400-1000% depending on the kernel rev. /b On Feb 15, 2010, at 3:41 PM, Paulo Vicentini wrote:
I will try to enable such feature in core.db ( I want to use just RAM core.db and to disable all other databases) If I use FS exclusively as a SIP gateway ( no registrar ) I think I can "disable" the use of such sofia tables (Does it make sense? ) :
.tables sip_authentication sip_shared_appearance_dialogs sip_dialogs sip_shared_appearance_subscriptions sip_presence sip_subscriptions sip_registrations
Thank you Paulo
Hello, "The core will open the db multiple times so you would end up with many instances not linked to each other." I think it might work with just one core.db handle, right? "If sofia uses it, it needs it, or else it would've been an optional configuration option." As I can see until now, if mod_sofia were used just as a gateway (that is my aim) it would be able to bypass sip related tables/code and it might have a compile option for that scenario as well... "How hard are you hitting this box to kill it because your data base ? What distro are you on?" I intend to use my hacked FS version on Debian / Kernel 2.6.23.8 / soekris Thank you, Paulo On Mon, Feb 15, 2010 at 7:45 PM, Brian West <brian@freeswitch.org> wrote:
How hard are you hitting this box to kill it because your data base ? What distro are you on? Some versions of the linux kernel slow SQLITE down by 400-1000% depending on the kernel rev.
/b
On Feb 15, 2010, at 3:41 PM, Paulo Vicentini wrote:
I will try to enable such feature in core.db ( I want to use just RAM core.db and to disable all other databases) If I use FS exclusively as a SIP gateway ( no registrar ) I think I can "disable" the use of such sofia tables (Does it make sense? ) :
.tables sip_authentication sip_shared_appearance_dialogs sip_dialogs sip_shared_appearance_subscriptions sip_presence sip_subscriptions sip_registrations
Thank you Paulo
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
This is all unnecessary, just toss them on tmpfs and call it a day. Mike On Feb 16, 2010, at 6:04 PM, Paulo Vicentini wrote:
Hello, "The core will open the db multiple times so you would end up with many instances not linked to each other."
I think it might work with just one core.db handle, right?
"If sofia uses it, it needs it, or else it would've been an optional configuration option."
As I can see until now, if mod_sofia were used just as a gateway (that is my aim) it would be able to bypass sip related tables/code and it might have a compile option for that scenario as well...
"How hard are you hitting this box to kill it because your data base ? What distro are you on?" I intend to use my hacked FS version on Debian / Kernel 2.6.23.8 / soekris
Thank you, Paulo
On Mon, Feb 15, 2010 at 7:45 PM, Brian West <brian@freeswitch.org> wrote: How hard are you hitting this box to kill it because your data base ? What distro are you on? Some versions of the linux kernel slow SQLITE down by 400-1000% depending on the kernel rev.
/b
On Feb 15, 2010, at 3:41 PM, Paulo Vicentini wrote:
I will try to enable such feature in core.db ( I want to use just RAM core.db and to disable all other databases) If I use FS exclusively as a SIP gateway ( no registrar ) I think I can "disable" the use of such sofia tables (Does it make sense? ) :
.tables sip_authentication sip_shared_appearance_dialogs sip_dialogs sip_shared_appearance_subscriptions sip_presence sip_subscriptions sip_registrations
Thank you Paulo
we already looked at this long ago it only supports 1 db of this nature and it cannot be shared. its not going to happen. On Tue, Feb 16, 2010 at 5:47 PM, Tamas <jalsot@gmail.com> wrote:
Hello,
this feature sounds interesting in case of running FS as a softphone base, where access rights are usually limited and not straightforward to make tmpfs. Also running from something like readonly filesystem it could be interesting addon (this won't solve the write requirements of logs and conf directory though).
Regards, Tamas
Michael Jerris írta:
This is all unnecessary, just toss them on tmpfs and call it a day.
Mike
On Feb 16, 2010, at 6:04 PM, Paulo Vicentini wrote:
Hello, "The core will open the db multiple times so you would end up with many instances not linked to each other."
I think it might work with just one core.db handle, right?
"If sofia uses it, it needs it, or else it would've been an optional configuration option."
As I can see until now, if mod_sofia were used just as a gateway (that is my aim) it would be able to bypass sip related tables/code and it might have a compile option for that scenario as well...
"How hard are you hitting this box to kill it because your data base ? What distro are you on?" I intend to use my hacked FS version on Debian / Kernel 2.6.23.8 / soekris
Thank you, Paulo
On Mon, Feb 15, 2010 at 7:45 PM, Brian West <brian@freeswitch.org> wrote:
How hard are you hitting this box to kill it because your data base ? What distro are you on? Some versions of the linux kernel slow SQLITE down by 400-1000% depending on the kernel rev.
/b
On Feb 15, 2010, at 3:41 PM, Paulo Vicentini wrote:
I will try to enable such feature in core.db ( I want to use just RAM core.db and to disable all other databases) If I use FS exclusively as a SIP gateway ( no registrar ) I think I can "disable" the use of such sofia tables (Does it make sense? ) :
.tables sip_authentication sip_shared_appearance_dialogs sip_dialogs sip_shared_appearance_subscriptions sip_presence sip_subscriptions sip_registrations
Thank you Paulo
------------------------------
_______________________________________________ FreeSWITCH-dev mailing listFreeSWITCH-dev@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswi...
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
Hi, "this feature sounds interesting in case of running FS as a softphone base" Yes... I additionally did a FS_SIP_REGISTRAR_MODE (mod_sofia) compile flag so that SIP registrar related things are stripped and it does not need to create mod_sofia databases... Regards Paulo On Tue, Feb 16, 2010 at 11:49 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
we already looked at this long ago it only supports 1 db of this nature and it cannot be shared. its not going to happen.
On Tue, Feb 16, 2010 at 5:47 PM, Tamas <jalsot@gmail.com> wrote:
Hello,
this feature sounds interesting in case of running FS as a softphone base, where access rights are usually limited and not straightforward to make tmpfs. Also running from something like readonly filesystem it could be interesting addon (this won't solve the write requirements of logs and conf directory though).
Regards, Tamas
Michael Jerris írta:
This is all unnecessary, just toss them on tmpfs and call it a day.
Mike
On Feb 16, 2010, at 6:04 PM, Paulo Vicentini wrote:
Hello, "The core will open the db multiple times so you would end up with many instances not linked to each other."
I think it might work with just one core.db handle, right?
"If sofia uses it, it needs it, or else it would've been an optional configuration option."
As I can see until now, if mod_sofia were used just as a gateway (that is my aim) it would be able to bypass sip related tables/code and it might have a compile option for that scenario as well...
"How hard are you hitting this box to kill it because your data base ? What distro are you on?" I intend to use my hacked FS version on Debian / Kernel 2.6.23.8 / soekris
Thank you, Paulo
On Mon, Feb 15, 2010 at 7:45 PM, Brian West <brian@freeswitch.org>wrote:
How hard are you hitting this box to kill it because your data base ? What distro are you on? Some versions of the linux kernel slow SQLITE down by 400-1000% depending on the kernel rev.
/b
On Feb 15, 2010, at 3:41 PM, Paulo Vicentini wrote:
I will try to enable such feature in core.db ( I want to use just RAM core.db and to disable all other databases) If I use FS exclusively as a SIP gateway ( no registrar ) I think I can "disable" the use of such sofia tables (Does it make sense? ) :
.tables sip_authentication sip_shared_appearance_dialogs sip_dialogs sip_shared_appearance_subscriptions sip_presence sip_subscriptions sip_registrations
Thank you Paulo
------------------------------
_______________________________________________ FreeSWITCH-dev mailing listFreeSWITCH-dev@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswi...
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
We do more than our fair share of working with the community and we have no room whatsoever for talking about people doing local mods that we are not willing to support. Can we end this thread now?, everything discussed in it is pure fantasy anyway. I officially change the subject to "Come to ClueCon MMX" On Wed, Feb 17, 2010 at 3:53 PM, Paulo Vicentini <vicentini.paulo@gmail.com>wrote:
Hi, "this feature sounds interesting in case of running FS as a softphone base" Yes... I additionally did a FS_SIP_REGISTRAR_MODE (mod_sofia) compile flag so that SIP registrar related things are stripped and it does not need to create mod_sofia databases...
Regards Paulo
On Tue, Feb 16, 2010 at 11:49 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
we already looked at this long ago it only supports 1 db of this nature and it cannot be shared. its not going to happen.
On Tue, Feb 16, 2010 at 5:47 PM, Tamas <jalsot@gmail.com> wrote:
Hello,
this feature sounds interesting in case of running FS as a softphone base, where access rights are usually limited and not straightforward to make tmpfs. Also running from something like readonly filesystem it could be interesting addon (this won't solve the write requirements of logs and conf directory though).
Regards, Tamas
Michael Jerris írta:
This is all unnecessary, just toss them on tmpfs and call it a day.
Mike
On Feb 16, 2010, at 6:04 PM, Paulo Vicentini wrote:
Hello, "The core will open the db multiple times so you would end up with many instances not linked to each other."
I think it might work with just one core.db handle, right?
"If sofia uses it, it needs it, or else it would've been an optional configuration option."
As I can see until now, if mod_sofia were used just as a gateway (that is my aim) it would be able to bypass sip related tables/code and it might have a compile option for that scenario as well...
"How hard are you hitting this box to kill it because your data base ? What distro are you on?" I intend to use my hacked FS version on Debian / Kernel 2.6.23.8 / soekris
Thank you, Paulo
On Mon, Feb 15, 2010 at 7:45 PM, Brian West <brian@freeswitch.org>wrote:
How hard are you hitting this box to kill it because your data base ? What distro are you on? Some versions of the linux kernel slow SQLITE down by 400-1000% depending on the kernel rev.
/b
On Feb 15, 2010, at 3:41 PM, Paulo Vicentini wrote:
I will try to enable such feature in core.db ( I want to use just RAM core.db and to disable all other databases) If I use FS exclusively as a SIP gateway ( no registrar ) I think I can "disable" the use of such sofia tables (Does it make sense? ) :
.tables sip_authentication sip_shared_appearance_dialogs sip_dialogs sip_shared_appearance_subscriptions sip_presence sip_subscriptions sip_registrations
Thank you Paulo
------------------------------
_______________________________________________ FreeSWITCH-dev mailing listFreeSWITCH-dev@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswi...
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
participants (6)
-
Anthony Minessale
-
Brian West
-
Mathieu Rene
-
Michael Jerris
-
Paulo Vicentini
-
Tamas