Perl driver...

3 views
Skip to first unread message

Jon

unread,
Dec 4, 2009, 1:17:52 AM12/4/09
to mongodb-dev
So in my environment I can't keep sockets open and re-use them
easily. As a result we just connect for every read/write as needed.
Not a big deal most of the time. The issue I have is with the Perl
driver (which so far as been very good). I tracked my issue down to
there being no real "disconnect" method. Deleting the object doesn't
seem to help since it doesn't have a DESTROY to clean up after itself.

But after looking at the source I installed from (btw, requiring a
local server running for the tests was a bit of an issue at first) I
figured out that I just need something like the mongo_link.c
check_connection method but without the return mongo_link_connect.
That return forces it to always re-establish which is why my server
falls over during load testing (runs out of threads of all things).

Which also brings up an interesting point of, server scalability might
be an issue if you have to maintain a thread per client and and you
use persistent connections on multiple programs on many servers at
once. My small test fell over at 300 threads. :)

Think we could get a patch for the driver? I can probably patch my
own, but something more official seems like a good idea since I'm
probably not the only person in the world that will have this issue.

Thanks.

Kristina Chodorow

unread,
Dec 4, 2009, 10:07:57 AM12/4/09
to mongo...@googlegroups.com
Are you using the latest version, .26?  If not, I'd recommend upgrading, it fixed a bug with sockets staying open on some setups, which I think is the problem you're seeing.  The driver doesn't actually support persistent connections yet (although I'm hoping to add that to the next version).

By the way, there is a DESTROY (see the last method in xs/Connection.xs).

check_connection immediately returns if you're connected, it only tries to reconnect if the last time it tried to connect to the database is unsuccessful (e.g., the database crashed, the network was down, etc).  You can suppress this behavior by passing auto_reconnect => 0 to the constructor, but I doubt that's what you want.



--

You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To post to this group, send email to mongo...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-dev?hl=en.



Jon

unread,
Dec 4, 2009, 1:52:17 PM12/4/09
to mongodb-dev
I am using 0.26. And I noticed the DESTROY statement later. So I'm
using a wrapper object that takes care of connection information and
such and I store my Mongo objects on it. Then when I "disconnect" on
my object I just delete the Mongo objects from my object. It might be
my using the delete on a hashref is causing it to skip the DESTROY or
something weird (I've seen this happen before). But I'll see about
getting more details together today, I posted a list for git yesterday
on the IRC channel with my server log showing only connects.
> > mongodb-dev...@googlegroups.com<mongodb-dev%2Bunsu...@googlegroups.com>
> > .

Kristina Chodorow

unread,
Dec 4, 2009, 1:59:38 PM12/4/09
to mongo...@googlegroups.com
Aha!  The closing connections bug fix actually went in the day after .26 was released.  Could you try the latest code?  (http://github.com/mongodb/mongo-perl-driver)?  Sorry.


To unsubscribe from this group, send email to mongodb-dev...@googlegroups.com.

Jon Stephens

unread,
Dec 4, 2009, 5:04:05 PM12/4/09
to mongo...@googlegroups.com
So yes, I created my own patch (we use rpms for everything library related).  You can view it here:  http://gist.github.com/249342
If you're like me and use cpan2rpm whenever possible you would do something like this:
* copy patch file to say root's home directory
* run: cpan2rpm --release custom --force --make-no-test --patch="/root/mongodb_perl_0.26_close.patch" MongoDB
The make-no-test is cause of failures even with a local MongoDB running.   But I verified that the things it complained about weren't an issue.
Reply all
Reply to author
Forward
0 new messages