Shopping List - BUG ??

[NVL]

Have spent a few hours testing this...

In Actinic Business V7.01 a registered client loads up their shopping list which works through to checkout so long as normal products are contained however should you load that same list and subsequently add a product built from components with associated products within said components a 500 error is returned upon clicking checkout.

I don't have any products built without components that don't have associated products to see if that's the key to this, it could be just the component built products themselves which are the issue.

FYI the products (with components as above) cause no error when added to cart manually, either alone or with other normal products. Only when the shopping list is loaded will this error happen.

[NVL]

Additional info...

The error occurs only when you reach 123 products in shopping cart and have component derived products within, the shopping list may not be the problem at all...

I think it's related to the components and number of total products, we just sat and added the order up one piece at a time without using the shopping list and replicated error when we hit 123 in cart. If you then remove the component derived products you can continue...

NB : You can continue to shop and add items past 123, the error only shows when you click checkout if 123+ items are in cart and at least one is component derived.

[cdicken]

David

The error you have found is very likely to be you hitting the limit of the processing power available on the server for handling Perl execution. We normally recommend 16MB, which will handle orders up to about 100 or so lines.

You have succeeded in finding exactly how big an Actinic shopping cart can get on your server. If you want them to be bigger than 123 items then you need to ask your web hosts for more processing resources assigned to Perl.

[NVL]

The available load is greater than that Chris and it's not 123 lines, it's 123 products of varied multiples...

If your theory were correct then how could we add more than 123 products and see it work by removing the component based products? In tests we went as far as 200+ products... Had the available processing resource for executing cgi been the issue we couldn't have worked around this by removing just two products at the error threshold and subsequently adding another dozen standard products, the latter would have been a greater call upon resources.

The 123 seems important to me, like a developer writing a script and keying 1-2-3 in the beta. The component based products at the 123 total products in cart must be a trigger for an IF / ELSE or similar.

Sorry to disagree...

[cdicken]

OK - I'll pass all this on to the Development team and get them to investigate. Many thanks.

[zmagyar]

The 123 seems important to me, like a developer writing a script and keying 1-2-3 in the beta. The component based products at the 123 total products in cart must be a trigger for an IF / ELSE or similar.

Actually I'm aware all of the script changes either as the implementer or the reviewer but I'm not aware of such a hard coded limit. You can also ensure by executing a search on the scripts for the string '123'.
Anyway just to be sure our QA team ran a quick test on the scripts and the checkout could be done when more than 123 items was in the cart (using different product combinations).

a 500 error is returned upon clicking checkout.

According to RFC 2616 this error means: "The server encountered an unexpected condition which prevented it from fulfilling the request." This is down to one of the following reasons most of the cases:

• The script crashed before the html output was provided
• The script didn't provide an output within the timeout perid of the server
• The script was shut down due to resorce limitation of the server

You can check the server's error log to see the exact reason. However if you are experiencing the problem only during the checkout (or a particular step of the checkout) then it is almost sure that the script exceeds the server's resource limt (CPU or memory) which leads to the 500 error.

Regards,

[NVL]

123 Products

Did you add 123 products and then add a purely component based product? The component based product was the key...

I use Easyspace to run a PPC search engine which has scripts WAY beyond that of Actinic, having run this for years we've spoken with Easyspace several times and the only real limit they have which is unreasonable is a limit upon threads in SQL.

According to their error logs there's been no issue, other than a script crashing ... no timeout, no resource limit.

What they have said is that at the time of us running this test they had reduced the processing resource for CGI but to 16Mb. So ok the thing works now but I feel a question is due; what caued such a quantum jump in required resources to execute this perl script from adding a component product..?

So it's Twilight Zone for now, we'll continue to monitor...

[zmagyar]

Did you add 123 products and then add a purely component based product? The component based product was the key...

AFAIK our QA team did this test but I have posted a query to them to double check this configuration.

So ok the thing works now but I feel a question is due; what caued such a quantum jump in required resources to execute this perl script from adding a component product..?

It is not a real quantum jump. Actually the performance bottleneck is the order encryption which uses the resources heavily. Each component represented in a separate order line, therefore there is a linear increase ion the requred amount of resources.

Regards,