"Order" and "add to.." perl scripts

[wfl]

I have been trying all afternoon to test some V6 Dev Actinic work but the order and cart perl scripts keep falling over and others work fine.

I have refreshed the scripts from new to no avail.

One script in particular, the checkout script os000002.pl falls over every time and sometimes the “add to cart” script ca000002.pl does the same. The result is a 500 error, “page cannot be displayed”.

I am using plain credit card sent separately and pay by cheque.

All the other scripts seem to work ok.

The config (paths) is the same format as other sites on the same Solaris box.

[NormanRouxel]

Itermittent faults like yours are often because the server times out when processing these big scripts. A maximum execution time has been set for Perl scripts by your ISP and the load on the server (especially if it's shared) means that time is exceeded.

Also possible is that the server hasn't enough memory free to run them. This often caused the checkout to fail if there are lots of items with lots of choices in the cart. Again your ISP may have set a limit on how much memory a Perl script can have and the complex carts exceeds this.

There have been other postings recently regarding this. And some solutions posted that involve installing some Perl modules (these may need your ISP's co-operation) that speed things up. Try searching this and the V6 Forum for "timeout" or "perl" or "MD5" to see what's been written about these.


Norman

[wfl]

Thanks Norman

I take it the issue has only krept in with V6.

We have several V5s running on the same server and others without a problem. The box runs weatherfront.biz and that flies.

At the moment I am working on the next generation of Weather Front on a new domain but with the V5 Weather Front site imported/upgraded from Catalog into V6 Dev.

ISP is a mate so cooperation no prob. He is going to look at timeout to see if that has anything to do with it.

It is certainly not memory or number items in the cart (I am testing with one item at a time).

The "add to basket" error happens pretty instantly when it does.

The main error is the checkout and this occurs at the redirect from the basket view.

I have stripped everything other than UK out of payment, tax and shipping and tried it with location selected and not but it all gets the same result.

[NormanRouxel]

If you've access to your severs error log then that may explain exactly why it failed.

Also check the other postings I mentioned as there is a lot of info in there regarding the Perl resources required.

Also try the knowledge base (link at top right of this page) - search for "Error 500".


Norman

[pinbrook]

have you changed the perl scripts....the 2 you talk about are generated by

shoppingcart.pl and orderscript.pl

500 errors are often caused by syntax errors in these scripts

[wfl]

Norman

The error log is clean.

I have had a look through the knowledgebase (when it deems to work) and found a similar problem. The solution offered there was increasing the memory available to 12Mb but that is not relevant to the scripting on our Solaris box.

I think also that the server runs md5 but we are going to get our Unix tech man to look at it.

Jo

No the scriplts are both out of the box standard. I am trying to do this version of ours site with minimal bespoking to the HTML and CUSTOMVARS and I definitely want to leave the scripts alone.

I am on 6.1.2 DDVA

OrderScript.pl is 03/03/2003 and ShoppingCart.pl is 24/02/03.

I see that the generated scripts are a lot closer in size to the originals in my V6 than in V5.

I think we have to concentrate on timeout and have a look at the memory issue. I don't know what our Unix Tech man is up to over the weekend but I am sure he will look in.

[NormanRouxel]

I see that the generated scripts are a lot closer in size to the originals in my V6 than in V5.

Ahah! Try going to Design / Options / Miscellaneous and turn off Compact HTML/CGI.

This will reduce the size of the cgi-bin scripts considerably.

Norman

[wfl]

Oh yes, that explains the file size

Unfortunately it was a nice thought but it doesn't solve the problem wich obviously lies in the processing.

When you hit checkout the error 500 page occurs at;

http://www.domain.co.uk/cgi-bin/os00...2findex%2ehtml

I don't see all the REFPAGE.... bit in a V5 shop on the same server so do I assume what I am seeing in the error is the bit that fails?

If so does that help locate the problem?

[cdicken]

The REFPAGE.... bit is new to v6 (it tells the script what the last page was that you visited) and it won't be the thing causing the problem.

When you click the 'Test' button in 'Advanced | Network Setup' what message do you get. Do you receive any errors?

Also, go to 'Help | Troubleshooting' and click 'Website Analysis'. This gives a whole load of diagnostic infomation and may contain some useful pointers.

[wfl]

Chris

Actually the REFPAGE bit is not giving the last page but always the catalog root page i.e. shopindex.html.

The only error I get on test is "not an SMTP server" but I always get that with the particular sever even though it is and it works OK.

That is also the only error I seem to get with "website troubleshooting>website analysis" along with an invalid receipt email address (because it is currently an invalid address).

[cdicken]

What is the URL of the faulty site? Apologies if it is in the thread somewhere and I have not seen it.

If we can see the error happening for ourselves then maybe we can give you further help.

Otherwise you could raise an email support request here and the email support team can take a close look at what is happening.

[wfl]

Chris

I had not posted the URL because I am aware of one or two competitors who use Actinic.

Can you email me at alistair@windwardquay.com and I will email you the URL by return?

[cdicken]

I'm no server expert - I was hoping someone else on the forum would have an idea.

I suggest you register an email support request and deal with it away from this forum.

[wfl]

An update for anyone who is interested.

The Unix box we are using a Sun Solaris and is running MD5 with no memory restrictions.

To get over the problem with the OrderScript Actinic have sugested installing a their own perl module ActEncrypt1024 and an Appche mod_perl module to solve the problem. Apparantly the consesus at Telehouse is that these lead to memory leakage and are not wholy satisfactory.

Our ISP's techies tell me that the Actinic perl is trying to use a bit of Microsoft with com objects and to access mdb.

The perl mods may be OK on a dedicated box but our ISP's tech man is loathe to mod the perl on a shared box where other users may be relying on the original perl.

We and our ISP are continuing to look into this but it is not a priority as we feel that it should be up to Actinic to provide a satisfactory run anywhere product. To that end we can't currently host Actinic V6 on Unix (Sun Solaris).

The solution we are opting for is to run it on a W2003 (please forgive me) box where it works fine. Of course it would do wouldn't it because Microsoft's version of perl understands things like com objects! Obviously we can only run Beta until July 1 but that is not a problem for the current projects we have on.