A General Script Error Occurred!?

[Helpless]

Hello, yesterday I finally went to upload our actinic site in a very vague test format - it still needs much work - to our host, I set all the configuration up and managed to put it all on the server, but now every time I click checkout (or in our case "order") I get an error that I can't understand.

A General Script Error Occurred
Error:

The site configuration has been updated by the shop operator while you are checking out. Please navigate back to the product pages by pressing the Browser Back button and try again or contact the site owner. Press the Browser back button and try again or contact the site owner

This might be understandable if I had changed the config at all since uploading. How do I go about fixing it?

Also, if I want to delete the files from FTP and start uploading again, will actinic be ok, or will it throw up some chuffing error because the files it expects aren't there? The main aim being that at current I've got it in /acatalog, but I really need to have it in root /.

Any help would be most appreciated.

[Helpless]

Indeed, I found this link (http://www.actinic.com/cgi/ss000007.pl?PRODREF=CD140&NOLOGIN=1) explaining the exact situation, but that is no good because I'm already running the most recent version (6.0.2) and have no control over whether its shared SSL or not.

My other queries still stand, though. I really need to shift the whole thing up a dir. to root.

[triggerhippie]

I have a similar problem it now says that there is no refering data passed..

I have contacted Actinic Support without joy - they have no reference of this.

I have also used the last versions of actinic on our servers without problems and this is the first it must be said.

Here is my error log file from the 'Acatalog' directory that happens when you press the 'go checkout' button:

Internal Server Error, this is an error with your script, check your error log for more information.

goes from the following script

1) cm000001.pl

then redirects to....

2) http://www.website.co.uk/cgi-bin/os000001.pl?ACTION=Start%21&REFPAGE=http etc etc

If anyone has an idea i would be pleased to see a solution before I revert to an old version to get the clients site finished.

UNIX / PERL 5 / PHP / MySQL etc Globals Off.

[Neo_ad]

i had something like this but i solved it by changing my domain from .co.uk in the network settings to .com as all the actinic stuff is on the .com side and the .co.uk just re-directs to .com

This only would affect you if u have a .co.uk + .com domain for same shop :)

Regards,

Stewart

[triggerhippie]

Hiya, - only co.uk domain on this but thanks for reply much appreciated...

Hmmm setup another web area just in case and still get an error .......

this time I have an error log from my server:

[Sat Feb 22 09:34:53 2003] [error] [client 213.78.66.36] Premature end of script headers: /domains/w/e/website.co.uk/public_html/cgi-bin/os000001.pl

its at the following: www.elementsgifts.co.uk

Any ideas helpfull - no other pages / scripts on this site at the moment oh yeah .....Actinic V6.0.2 upgraded.

HELP !

[andyk]

Hiya,

I received the same error... i rang actinc support and they said there was a bug in 6.02. I was emailed some replacement perl files and instuctions, which i followed and now the shop works perfectly.

Drop me an email (andy@phase8.com) if you want to give the files a go, and i'll forward em to you.

[r4z0r]

I had the same problem, however all I did was view the cart, it then said there was nothing in the cart, so I added something tried the checkout again and it was fine.

[pinbrook]

I just had the same problem at the end of a checkout while testing a site. How about posting these fixed perl files on your website Actinic? ;)

Nick Morecroft.

[triggerhippie]

You dont know how relieved you guys have made me feel
(face relaxing) I thought I would be stuck out in Nosolution land
on my own without hope ....

I shall be chasing the offer of perl help - and thanks again for the sheer relief you gave me as I thought I had some strange server behaviour and I was the only one ....aghhhh.

Ok it remains to be seen if the fix works but I am closer to a solution than before - will post result here ..

Thanks
Desperate Dimitri - client is anxious and too 'big' to be crossed !

[triggerhippie]

Got this email from my hosting company, and it doesn't look good:
==========================================
Hi,

Thank you for your email.

The error that you are seeing is the same error we always have with Actinic. Actinic scripts use too much memory when they execute, resulting in the error you see. Older versions of Actinic use less memory and therefore work fine.

You most likely will not be able to get the version 6 Actinic to work on our servers, so I would remain with version 4 if you have a choice.

Kind Regards,
===========================================

Yes I know its like kicking yourself in the head if thats their real response to the problem ....but stuck in nowhere land again until
I try the script changes and see if these somehow work.

If this is true I would love to know whay it's so memeory intensive? - over to you Actinic...

[zmagyar]

Originally posted by pinbrook
How about posting these fixed perl files on your website Actinic?
This issue will be fixed in the next v6 release (should be out within a few weeks). Meanwhile the following quick fix hopefully will do.

Open Session.pm in your site forder and find the lines

if ($Self->{_NEWSESSIONFILE} &&
!$sCallerID)

This should be changed to

if ($Self->{_NEWSESSIONFILE} &&
!$sCallerID &&
$::g_InputHash{'ACTION'} ne ACTINIC::GetPhrase(-1, 113))

Saving the changes and uploading the site should resolve the issue.

Originally posted by triggerhippie

Yes I know its like kicking yourself in the head if thats their real response to the problem ....but stuck in nowhere land again until
I try the script changes and see if these somehow work.

If this is true I would love to know whay it's so memeory intensive? - over to you Actinic...
This has been reported a few times already and we are considering the resolution.

It is true that the server side memory requirements has been increased since v4. But if you check the number of new features of v5 or v6 it is understandable IMO. The new features required more complex scripts and data structures.
The increased resource requirement has been recognised after v5. Therefore v6 already contains some improvements (e.g. better modularisation of scripts). Most likely the next major release will also address some of the online performance issues.

By the way the mentioned 8MB memory is not only for our scripts but it includes the perl environment and some system data.

I must also mention that the ISP can optimise the webserver for Actinic (as lot of them do). Not only the memory requirement can be decreased in this way but the online performance can be improved (significantly if you use Business).
If your ISP is willing to consult about this then you can suggest the followings:
- Install mod_perl (if not installed so far) - this provides high performance keeping the perl interpreter in the server's memory.
- Install Digest-MD5 perl package - Catalog uses this encryption frequently and uses our own (slow) perl version if the binary one is not present.
- Install the binary version of our 1024 bit encryption library which makes the order recording faster.

Knowledge Base Article Ref: CD185 may provide more info about this.

I hope this helps.

Sorry if I was too technical (I used to be :))

Regards,

Zoltan
Actinic

[andyk]

Hiya,

For anyone that wants it, i've attached the fix i was given and the instructions below:

Please try the following
This is assuming you are exploring the C:\Program Files\Actinic Ecommerce v6

In your site/site1 directory please delete all the .pl and .pm files
Next go into original folder and copy the .pl and .pm into the site/site1 directory

Once you have done this, extract the zipped file into your site\site1 directory and let it overwrite

Once this is done, open actinic and refresh the website

[triggerhippie]

Hi all,

I have been conversing back and forth between my hosts and this thred trying to resolve the script problem on checkout.

It has now reached the following stage and I wanted to show others what may be happening with actinic increasingly in the future.

Here is the reply from the MD of my (major hosting company) ressseler hosting provider.
=========================

I have stated that I don't think the changes you are requesting will make a reduction of the magnitude that we are looking for. If you have evidence the the contrary, i.e. figures, not just a statement that it will reduce memory usage, please let me have it. If the proposed changes can be shown to make the required reduction, and you will agree to pay for our man hours if they do not, we will install them.

I am not prepared to compromise the quality and reliability of our
service by increasing the memory limit on our reseller servers. Whilst I have no issue with your order script using the amount of memory you desire, I cannot increase the limit to enable it to do so as doing so would make it possible for a fork bomb type cgi script to consume all available system memory. Due to the type of hosting plan you are buying, you must accept that not all end users of our hosting will be particularly responsible and we would have many problems with malicious activity from end users (who have often obtained their hosting free of charge through a reseller and hence have nothing to loose by being malicious) if our servers were not locked down as tight as they are.

Ultimately, at ****** reliability and performance is always placed
above functionality. We achieve 100% uptime and excellent speeds in third party tests http://www.webperf.net.

Our proposed solution to your problem is a dedicated server, where the problem of malicious use is not present and limits can thus be relaxed.
==============================

I would love to hear evidence for obvious reasons as to how much the new fixes to come soon will reduce server load sufficiently - I tried the fixes proposed - both the ssl.zip one and the alterations to the session.pm without success

Dimitri

[NormanRouxel]

Could you share with us which service provider you are having these problems with?

Norman

[garyhay]

Well I am sorry but I just have to get a 2p worth in here.

I like Norman would like to know who your provider is. I would also like to know what you are paying them and what Reseller plan you are on.

Ask them how much Flash files reside on the server and what the memory useage is for these.

Why not offer to buy them 256Mb of RAM, cheaper than a dedicated server then you can run Actinic Host :D

[pinbrook]

Yep,

I feel these guys are running rings around you.....there are better hosts out there who won't fobb you off with such excuses

[andyk]

check out actinic's hosting partners page i'm sure you'll find someone there that will be a reliable host!

[triggerhippie]

Ok ok, have to say though they have been excellent on all counts and performance has been 100% - If what was said is true, hten I can understand it.

I have also spoken to someone in Actinic who knos them and has apparently spoken a few times with them to try and tackle this issue:

Donhost!

Please chaps be kind as they have been reasonable on all other counts and their price is very good for 1year reseller UNIX and all that goes with - approx £469.99.

Support is always there and ready to help ....it's just in this case that I am left scratching my head in disbelief ...

Let me know your thoughts :)

[pinbrook_nick]

I’ve just done some testing on V4, 5 and 6. I monitored the memory usage of the perl process while performing purchase actions. I took several readings, and here are the averages: (all figures in MB [Megabytes]).

Add to cart:
V4: 7.3
V5: 7.7
V6: 8.0 (10% increase from V4; 4% increase from V5)

Checkout button:
V4: 9.3
V5: 9.7
V6: 12.0 (29% increase from V4; 24% increase from V5)

Finish button on credit card encrypt:
V4: 9.5
V5: 11.9
V6: 13.0 (37% increase from V4; 9% increase from V5)


I took these readings using perl on my PC. Therefore the memory usage would probably be less on a web server – being more efficient. I may try this experiment some time on our own web servers - if I do, I’ll post the results.

The figures are a little rough, but should give an idea of the amount of increase in memory demand over the versions.

In my opinion, an increase from 9.5 to 13MB is not that significant. A 256MB stick of ECC memory costs about £50 right now. Advances in code require advances in hardware performance. Look at Windows today – cleaner, more user-friendly features and graphic rich, but at a cost of requiring more powerful PC’s. Fortunately web servers are more efficient, and require less frequent upgrading. I have been using V6 on our web server with any apparent performance related problems so far.

[zmagyar]

Nick,

Thanks a lot for posting these figures. It is good to see an independent performance review. :-)

However I must mention there are several infulencing factors. E.g.
- installed apache modules
- installed perl modules (MD5, ActEncrypt1024)
- Catalog configuration (shipping, tax, etc settings)
- the size of your site (number of products, price schedules, etc)
In other words these figures can either be better or worst (some sites require 16MB to complete the checkout). But the tendency can perfectly be seen. I believe this memory requirement increase is understandable comparing the features of different versions.

On the other hand I can understand the ISP point of view as operating shared servers requires lots of trade off. Depending on their performance/security standard they might or might not want to do this change for you. It is their choice as you have the choice to find the suitable ISP which fits for your needs.

By the way I believe most of the confusion (especially from ISP point of view) is down to the interpretation of the word "script". They expect some tiny code which provides some dynamic content for the web pages. But believe me, a shopping cart application (especially as complex as Catalog is) can not fit in this size.

Anyway as I already mentioned we are taking these isses serious and investigating our scripts from this point of view. I'm pretty sure significant improvements can not be achived in maintenance releases but we are considering some online performance improvement in the next major release.

Regards,

Zoltan Magyar
Actinic Software

[garyhay]

You must be getting some overtime bonus. 10.30 at night WOW;)

[zmagyar]

I have flexible working hours (as all the developers) which means that I'm supposed to work all day. BTW it is 00:12 here. :)

Zoltan

[pinbrook_nick]

Thanks for the comments Zoltan - some handy info.

The tests I ran were all on the same platform (my PC running a standard install of ActiveState Perl). I also used the demo store in each version of actinic, and purchased a simple, single product for consistency. Hopefully that meant reasonably even figures.

I agree that there may be confusion over the word "script" for web hosts. But on the flip side, any web host offering "Actinic compatible" hosting should take into consideration the performance demands of Actinic when pricing the hosting package. If the web host has costs for server hardware, then each hosting package should be priced to pay for the percentage load it puts on the hardware (and bandwidth).

If web hosts believe that newer versions of Actinic (and any other evolving products) are putting a greater load on their servers, then perhaps they could offer hosting packages with pricing to match the version of software. On a features point of view, Actinic V6 is significantly more advanced than V4, therefore maybe people ought to be prepared to pay more for it's running costs - just as they are prepared to pay for the upgrade license.

If you upgrade from Windows 98 to XP, you might have to accept the fact that a hardware upgrade may be neccessary too.


The way web hosting is charged is an evolving situation. The main factor used to be the amount of disk space you got with your package. That has disappeared somewhat with the advent of massive cheap hard disks. Bandwidth is currently a cost issue for a number of hosts, and premiums are charged on wieldy database sites, which put a load on the processor(s).


I am not suggesting for a minute that hosts should start charging more for V6 hosting - I don't see us doing so for now (I personally don't think it demands that much more).

What I am saying for a situation like this, where a client's needs change mid-way through their hosting year is this:

A reasonable host who feels the client's needs have exceeded the specifications of their current package, could offer a more advanced package with higher specifications. If that is not in their power, then it may be time to look for another host. (If one of our clients exceeds the bandwidth limit of their package, we charge them extra that month. If it goes on month after month, we re-evaluate the package at the end of the year).

[zmagyar]

Originally posted by pinbrook_nick
The tests I ran were all on the same platform (my PC running a standard install of ActiveState Perl). I also used the demo store in each version of actinic, and purchased a simple, single product for consistency. Hopefully that meant reasonably even figures.
Thanks for the addition. Now it makes a good basis for comparision. I must say thank you again for doing and publishing this.
Originally posted by pinbrook_nick

I agree that there may be confusion over the word "script" for web hosts. But on the flip side, any web host offering "Actinic compatible" hosting should take into consideration the performance demands of Actinic when pricing the hosting package. If the web host has costs for server hardware, then each hosting package should be priced to pay for the percentage load it puts on the hardware (and bandwidth).
If the service is offered as "Actinic compatible" then I absolutely agree.

Zoltan
Actinic Software

[Ginnys Attic]

I must also mention that the ISP can optimise the webserver for Actinic (as lot of them do). Not only the memory requirement can be decreased in this way but the online performance can be improved (significantly if you use Business).
If your ISP is willing to consult about this then you can suggest the followings:
- Install mod_perl (if not installed so far) - this provides high performance keeping the perl interpreter in the server's memory.
- Install Digest-MD5 perl package - Catalog uses this encryption frequently and uses our own (slow) perl version if the binary one is not present.
- Install the binary version of our 1024 bit encryption library which makes the order recording faster.

Knowledge Base Article Ref: CD185 may provide more info about this.

Hi, I was unable to find the Knowledge Base Article Ref: CD185 (Muppet i know no doubt) i was just wondering where i or my host could get the binary version of the 1024 bit encryption library so it can be installed and if there was any further details and instructions on this so i could encourage my host to install it for us?

[NormanRouxel]

Welcone, Adrian

The previous reply on this thread was in 2003 so things may have changed a little since then.

Anyway the article referred to is http://knowledge.actinic.com/acatalog/Checkout.html#aCD185 but it doesn't really state more than you aleady know.

You may need to contact Actinic directly for info on that 1024 bit module.

[atulamigo]

Hello Mate

I am new user to this Actinic shopping cart. One of our client is facing following problem

A General Script Error Occurred
Error: Error opening configuration file /home/sites/www.website.com/web/acatalog/prompt.fil. No such file or directoryPress the Browser back button and try again or contact the site owner.

One thing about site is, it was working fine when it was on old server. Its hosting company switched this site to their CPANEL. and things get down.

Any one can help me please? Its really urgent.

Looking Forward From your Side

Thanks.
Cheers!!!
Atul

[Duncan Rounding]

Check folder permissions and run a network test and check for errors.

What's the URL?

[Darren B]

im guessing the network settings need changing, post these here and also your host

[ews.tom]

If this is any help to anyone -

This error was appearing when clicking View Cart or Checkout and stumped me for a while -

Turned out it was me adding the links myself that did it; the urls had CartPageURL and CheckoutPageURL variables as the hrefs, which were just linking to the perl scripts.

Changing these to CartLinkText and OrderLinkText fixed the problem - thanks to the gent on the Actinic support line!