Hey Guys,

Since moving to the newer code (6.9.5) I have seen several errors on the cart page. Obviously, these are rather concerning because of the sensitivity of the cart page.


I was able to recreate the error myself after it happened to a customer, but it went away of its own accord before long. Basically I got the email notification the error occurred and immediately recreated their cart on that website.

It happens when you have finished entering your address information and proceed to the next page of the cart where the shipping rates are displayed. Instead of loading that page, an error would occur.

Error Type:


That occurs here:


specifically on this line:


I'm assuming that this is related to the shipping rates being displayed and one of their servers not responding correctly. That of course is a crisis if it takes down the entire cart page. Is there a fix for this? Perhaps it can simply ignore that one carrier and show the other rates that DID populate?

- Graham Slaughter

Hi Graham

I'll do some testing on that but just to be sure, which shipping carriers do you have enabled?

Andy

Please feel free to review / rate our software

I have put through a few orders and finally got a connection problem to FedEx but that returned an error as it should

There seems to be a problem connecting to the shipping rates server. Please wait a few moments and refresh your browser, or try a different shipping carrier.
Authentication Failed

I'll try a few more as that would be the expected response to not connecting to a shipping carrier but it's a question of luck to get one to fail.

Andy

Please feel free to review / rate our software

quote:

---

[Microsoft][ODBC SQL Server Driver]Query timeout expired

---

Hi Graham
This is a timeout when trying to connect to your SQL Server database. Could it be that your host has been doing some updates or maintenance on the database recently? Normally things like this are short lived but if it persists then get on to your host and tell them you are having database connection problems.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Andy,

We have UPS, USPS, DHL, and FedEx enabled on our server.
It has occurred twice with an international customer / address (which displays all 4 shipping options) and it has happened twice on a domestic customer / address which displays only USPS, UPS, and FedEx

These errors were at
123pm CST Tuesday
132pm CST Tuesday

340pm CST Wednesday
402pm CST Wednesday


I agree that is was a bit of a crap shoot to get the error to come up. I know repeatability greatly helps in diagnosing and correcting an error. I can at least say with confidence that I was able to reproduce the error on Tuesday by immediately mirroring the cart of the customer and their address (which I doubt was specifically necessary) - but I cannot get the error to happen every time (if at all)


Vince,

We recently moved to new hardware with a faster clock speed on the CPU and we have started using extensive and aggressive caching, so there should technically be less stress on the hardware and database than ever before. It is important to note that this error has occurred nowhere else in all of the software. It has only occurred on the cart page where shipping rates are calculated and displayed. Additionally, we have several websites which we are migrating to the 6.9.5 code and it has ONLY occurred on those websites with the newer code. For example, I migrated one of our busiest websites to the new code yesterday. Prior to that migration we hadn't seen this error on that website. Within about 4 or 5 hours of the migration the error had occurred twice on that website. All the websites run on the same database / hardware / physical server.

I know that doesn't definitively indicate an issue with the code, but it is certainly a strong argument for it. I'll continue to update this ticket as / if the error persists. I may see if there is an easy way to setup transaction monitoring on the site to continually test that cart page while we look for and wait for a resolution.

Thanks as always guys.

- Graham Slaughter

I have setup a macro to refresh the cart page every 30 seconds to try and recreate the error. I'll let you know what happens.

- Graham Slaughter

Interestingly and thankfully I haven't been able to reproduce the error since opening this thread. I have refreshed the cart page many hundreds of time over the past week. Perhaps it was just the servers of one of the carriers being overwhelmed for a short while.

- Graham Slaughter

I finally had this error pop up again. It happened the day we migrated another site to the new code. In checking back on the other error instances, they were near to the date we migrated code on those sites as well. I'm guessing there is just something in the code that hiccups when the code is migrated. I want to say that the code we have now uses a different UPS URL for the rate requests. Perhaps UPS just has something in their server that doesn't like when you swap between rate querying URLs. Regardless, the issue appears to only happen within the 24 or so hours following a migration so it probably isn't worth looking into.

- Graham Slaughter

Hey Guys,

This popped back up today with a vengeance. None of our websites on the new code are working on the cart page.

Any of our sites that use the older version of the cart software are still working perfectly.

There must be a difference between the old and the new cart software that is causing an issue.

Please help! Not even rebooting the server has fixed the issue!

- Graham Slaughter

I think if it was a software issue we'd have heard about it from other users or would at least have come up in testing here. As Vince says, it appears to be a timeout to the database rather than a version thing, that could well be a red herring. Did you speak to your host about it being a connection problem?

Andy

Please feel free to review / rate our software

Woah. Ok, so I finally achieved a positive result. I'm not certain these things are related, but surely it is fuel for the fire so we can put a better fix on this.

For years now we have had a rule in IIS that filtered out a lot of bot traffic based on user-agent.

Last night I had turned that rule off for the first time in a LONG time. When I remembered, I turned the rule back on. The issue cleared up and the cart page works again! I don't KNOW that these things are related ... but I have no other answer for it.

While the issue persisted, there was very high CPU usage and there were a LOT of SQL processes that were marked as "Suspended"
There is still relatively high CPU usage, and there are still processes marked as "Suspended", but maybe the load on the server was high enough to be a tipping point? .... I don't know.


The funny thing is that the sites on the older version of the cart software are on the SAME server using the SAME database. Those sites didn't experience any interruption in cart.asp functionality.
Did the way the 2nd and 3rd cart pages interact with SQL server change in the last couple of versions?

- Graham Slaughter

Timeout to the database as a cause really only makes sense if there is a difference in how the cart page is coded in the newest version. Otherwise, you surely would expect the older versions of the cart software to have experienced an issue as well, right? But the older version continued to work perfectly during this outage.

- Graham Slaughter

Hi Graham
I'm glad you have a way to get the sites back up but can you send the rule that you turned on / off to my email and I'll see what kind of effect it may be having.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Done, thanks.

- Graham Slaughter