Brian Mark - Guitaraholic

Today, we had an XML process change so invalid XML was being returned (or changed invalid XML, because it's always invalid, but we had a fix for the prior version). Instead of just affecting us while the bad data was being returned, it actually lasted a little while longer. Why? Because we use memcached to store the result, lessening the load on our inventory management system. While it isn't normally an issue (most people don't deal with this oddball system), if we were storing those results longer than we had been, this could have been a huge issue. It was rendering product pages non-functional, which isn't a good thing. As a result of this, we're going to start doing more error checking and trapping. Oh what fun it is to deal with systems that don't care about being valid in the slightest and having Perl modules that require it.

As we're getting our new hosting platform in place, we've noticed a few issues popping up. The first larger issue was PayFlowPro from Verisign and their lack of support for 64 bit operating systems. That was easily worked around, but the next issue has me perplexed. The load balancers we're using work as NAT devices (Network Address Translation), so we have a private network behind them with all of our servers attached and the public network on the other side of them. All traffic to/from our servers goes through the load balancers, making for a firewall. To allow the web servers to talk to sites they want to visit (or request services and information from), NAT is used to allow for the public address of the load balancers to be used in the request to the servers on the other end. This works well for most things I've tried. OS updates install just fine (rather quickly over the large pipes our data center has, I might add). Payment related data works just fine (or at leas...