RE: [mv] Running Perl Process

["Russ Mann" <tech@khouse.org>]

Dear Kyle,

Thank you very much!  Just to make sure, is this new line supposed to be in
addition to the "current line", or should it replace the current line?  (I
just added it, because I wasn't sure).

I'm using Version 3.14-3, maybe Mike knows if that has the separate DB for
old IDs?

Thank you,

Russ

-----Original Message-----
From: minivend-users-admin@minivend.com
[mailto:minivend-users-admin@minivend.com]On Behalf Of kyle@invisio.com
Sent: Tuesday, December 12, 2000 10:02 PM
To: minivend-users@minivend.com
Subject: Re: [mv] Running Perl Process


Russ,

I remember that I used to get some hammered lock
problems (mv3.12), but for a long time now I've had almost none,
then when I read Mike's post (specifically point #2) I
remembered that I did a quick hack to Session.pm
to take care of an un-related (or so I thought at the time)
problem: customers getting the same session id from
external search engines.

So I added the following line to Session.pm in the read_session
subroutine near line 323 in my version:

$s = $Vend::SessionDBM{$Vend::SessionName}; #  current line in file

$Vend::SessionID = random_string() unless $s; #  -- my addition

It is very simple, if a session does not exist with a submitted
session id which should never happen*, then it simply invents
a new session id to be used from then on for this customer.

(* can happen from hardcoded external links, or possibly someone
sitting with their browser inactive for X amount of time where X
is the expire time for your sessions!)

It would be best to wipe out the session db when you restart, because
if there is heavy traffic from external hardcoded links, the session
may not get a chance to clear itself!

This hack was done before the fix in a latter version (MV 3.15 was it?)
where Mike set up a separate db of used session id's not to be
used again.

Hope this helps,
Kyle (KC)


At 01:53 AM 12/13/00 , you wrote:
>Quoting Russ Mann (tech@khouse.org):
>> Dear List,
>>
>> Ok, since I've never gotten a response on how to fix the hammered lock
>> problems, in the three years I've been using MiniVend, I'll take it
another
>> route.
>>
>> The problem comes when a minivend owned perl process starts gobbling up
CPU
>> at an alarming rate.  How can I "debug" MV to find out what routine this
>> gobbling is coming from?  Is there any way to check this, or put a cap on
>> it?
>
>The usual reason is one of the three following condtions:
>
>	1. Huge shopping cart, usually due to a bad robot
>	which orders every prodcut in catalog. Solve with
>	OrderLineLimit.
>
>	2. Affiliates (or yourself) who place the same session ID
>	in a link, causing contention and problems for that session.
>	Hard to solve except in MV4. One possiblity is to hack the
>	source to put in a list of IDs never to accept.
>
>	3. Huge more-lists built by searching and returning every
>	product in catalog. Can be solved only by hacking the source
>	in MV3.
>
>If MV3 were being actively supported, I would probably make these
>fixes (which are in MV4 and Interchange). But it isn't and I won't.
>
>[Thereby renewing my call for someone who has a case of masochism and
> wants to take over MV3 support. 8-) ]
>
>--
>Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
>phone +1.513.523.7621 fax 7501 <heins@akopia.com>
>
>I have a cop friend who thinks he ought be able to give a new ticket;
>"too dumb for conditions".
>
>_______________________________________________
>Minivend-users mailing list
>Minivend-users@minivend.com
>http://lists.akopia.com/mailman/listinfo/minivend-users


_______________________________________________
Minivend-users mailing list
Minivend-users@minivend.com
http://lists.akopia.com/mailman/listinfo/minivend-users


_______________________________________________
Minivend-users mailing list
Minivend-users@minivend.com
http://lists.akopia.com/mailman/listinfo/minivend-users