Thread: [Userlogin-users] Re: [Mason] UserLogin 0.5
Status: Beta
Brought to you by:
johnkeiser
From: John K. <jk...@in...> - 2001-09-01 23:40:48
|
On 01 Sep 2001 22:50:20 +0200, Amodiovalerio Verde wrote: > Hi John, > > it's quite working now, but there are some problem with Postgresql > connections. > > I don't know why but it seems that after a connect, the connection stay idle > like there was no disconnect at all. > > Pratically after about 20-30 reload it came out with a > > DBI->connect(dbname=userlogin) failed: Sorry too many clients already > > I was writing a kind of UserLogin module few month ago, and I got an > interesting start from a package already written for Perl, called Averist. I > have tested it quite extensively under Postgresql and Mysql and it works > fine. > I had some problem for cookie output, then i had to move to other job, so i > discontinue working on that Averist-Mason hack. > That is odd ... you using regular DBI or Apache::DBI? I think you will be OK with Apache::DBI (and your scripts will be more efficient). All you have to do is replace your use DBI; with use Apache::DBI; But what you are describing is probably a real problem, and I'll look into it. I have noticed that for some reason Perl isn't destroying my objects like I'd like them to :( > Now I had to work on that thing again, cause I'm working to a portal with > user base authentication. > > I'd like to know in which direction will UserLogin move, if there are any > other interested and so on. > > I think is unusefull to came up with two things that made the same thing. > > Let me know what do you think about it. > For UserLogin itself, short-term plans are to make the cache happier and have the example code encrypt the password before it gets sent over the wire. Long-range, I think the basic architecture is sound but I'm more than happy to hear suggestions. But the place where it gets interesting is, I'd like to end up building a suite of apps that use UserLogin--bulletin board, shopping cart & other ecommerce apps, content management. Really what I want to do is convert some existing utilities (like Mason-CM) to use it. This could become something like an application base--install this set of packages (conveniently bundled together), customize a few parameters and you have a dynamic website. Besides myself (I am using UserLogin in an upcoming shopping cart) there have been a few other people that have emailed me about it already. We should continue discussion about project direction in the mailing list though, I'm cc'ing this there. To look at the list, or subscribe, go to http://sourceforge.net/mail/?group_id=34123. --John |
From: Amodiovalerio V. <am...@wi...> - 2001-09-02 10:36:04
|
I look a little further inside UserLogin. I'm not so good with 'object-like' programming, but it seems that the DESTROY constructor in Postgres.pm is never called. So you end up with a bounce of connect until postgresql will complain. Well I'm going to debug it a little to see what it's happening. I look around using web search engine, and seems that other people has some problem with mod_perl, mason and the DESTROY constructor and looking in the perlobj page : When the last reference to an object goes away, the object is automatically destroyed. (This may even be after you exit, if you've stored references in global variables.) maybe there still some reference in a persistence connection ??? Valerio [Hypo] Verde |
From: John K. <jk...@in...> - 2001-09-02 18:51:41
|
On 02 Sep 2001 12:35:53 +0200, Amodiovalerio Verde wrote: > I look a little further inside UserLogin. > > I'm not so good with 'object-like' programming, but it seems that the > DESTROY constructor in Postgres.pm is never called. So you end up with a > bounce of connect until postgresql will complain. > > Well I'm going to debug it a little to see what it's happening. > > I look around using web search engine, and seems that other people has some > problem with mod_perl, mason and the DESTROY constructor and looking in the > perlobj page : > > When the last reference to an object goes away, the object is automatically > destroyed. (This may even be after you exit, if you've stored references in > global variables.) > > maybe there still some reference in a persistence connection ??? > Wow, thanks :) Well, what I think is going on there at least is the garbage collector isn't able to delete it immediately because there are circular references. Specifically, $sys holds a reference to $sys->{parameters}, which holds a reference back to $sys. I am thinking we may want to create a $sys->finished() method that does the same thing as DESTROY to alleviate these problems. I've opened a bug on this. I'll play with it and get finished() in today or tomorrow along with Mark Nickel's patch. --John |