Intermittent issues with (alatek) USPS plugin

[xvnate]

Greetings,
PHP Version     5.3.10-1ubuntu3.7
Joomla!         2.5.11 Stable [ Ember ] 26-April-2013 14:00 GMT
VirtueMart       2.0.22
Vm Shipment - USPS        V1.16

The issue that we are having is intermittent/random.  A large majority of the time, the usps shipping plugin works as expected for both domestic and international shipping calculations.  It is the only shipping plugin that we use.
The problem is the times when it can't come up with a shipping option and outputs the message:
"We are sorry, no shipment method matches the characteristics of your order."
This can occur for a domestic address or an international address and all required fields and data for both the address as well as product data, shopper group permissions, etc... are correct.  Remember, this only happens a small percentage of the time but our traffic is increasing so it is impacting more users now and it is problematic as we expand our international business as people can't really call in to order.
I have tried to find a way to reproduce the issue and so far, no one has figured how to do it and it's been months.  I'm beginning to wonder if the message is masking some other possible issue such as bogus data from usps maybe?
I don't want to inadvertently get this thread headed in a bad direction, but the one time that I had it occurring for me, I was able to clear it up by deleting the site cookies.  I lost my cart contents but was able to repopulate the cart and proceed.
I have two objectives:
1) how can I instrument the code so that I get a more helpful message that pinpoints the actual issue in a way that I can do post event analysis
2) how can I work the user through cleaning out just enough session data so that the shipping plugin recovers but the user doesn't lose session and their cart in the process.

Any help sincerely appreciated

[alatak]

hello

Remember, this only happens a small percentage of the time but our traffic is increasing so it is impacting more users now and it is problematic as we expand our international business as people can't really call in to order.

May be the reason is that there are too many requests to USPS at the same time.

May be i can add some caching to the request/response to USPS to lower the calls to them?
It is probably the solution.

[xvnate]

Hi,
I have some fresh information that I just collected from a test that was just performed.  It didn't go well but I can confirm that deleting the site cookies alleviates the situation.
During the test that just completed, I had 8 users running on a brand new servers and 80% of them encountered the issue.  One of them, I talked through deleting the site cookies and the order went through after they reloaded their cart (started over).

I can provide you with your own server with the exact configuration that we just tested against and give you full admin rights if you would like to see what we have setup here.
Thank you very much for your response no matter what else happens! 

[alatak]

Hello

But if it is cookie issue, it has nothing to do with USPS.
The plugin does not set cookies.

[xvnate]

Hi,
Does USPS do anything with session data?  By deleting the cookies, I believe that you break the session and a new one is created for you.
I'm sorry for the mis-direction by focusing on the cookie aspect; I believe that the issue is tied to session data at this point or at least that once the session data gets into a particular state with regard to USPS, the situation becomes hopeless.
Is it possible that there is some session data that is either confusing USPS or that USPS does encounter some sort of error but then isn't able to move past it because of session data?
Thanks,

[xvnate]

We are scrambling to rebuild the server and noticed the following when we went to get our OPC update:

Jul 18 2013 com_onepage2.0.159.zip
Change Log
- fixed the language issue with the vm2.0.22 new language files (now both legacy language files are supported together with the new language files)
- fixed email before payment option on virtuemart 2.0.22
- fixed OPC cache issue (now it caches UPS and USPS very well per cart and per country and zip)

Jul 12 2013 com_onepage2.0.157.zip
Change Log
- fixed a shipping issue on the first load of opc on vm2.0.22

Are you aware of any conflicts with with com_onepage?  If you recall, we had a very poor user test which was conducted on brand new servers so each person was essentially "on the first load of OPC" and the version of OPC we were running was older then these patched versions.
I will update when we have an idea if this fixed the issue or not but I would still be interested in pursuing a way to allow users to clean out any session data that might be hanging USPS up.
Thanks