Looks like the European Commission could use some high availability

Bear with me while I rant, please. Note: I love the concept of European integration, and I think despite all its shortcomings the EU is a great thing. But this is just an example of plain and simple WTF, and a very evident SPOF that is potentially affecting thousands of businesses in Europe at this time.

Background: Within the EU, we have the concept of intra-community supply, where business-to-business transactions between companies registered in different member states are (I’m oversimplifying) exempt of Value-Added Tax (VAT). In order to verify that the customer who receives the invoice is in fact a business, rather than a consumer, the burden is on the supplier to verify the customer’s VAT ID — a unique identifier for tax purposes.

To this end, the European commission provides a web site for manual VAT ID verification by humans. That site also hosts a SOAP-based web service for automated VAT verification by business-to-business commerce sites. Note: when this verification is unavailable, it means a supplier can either stop issuing invoices, or resort to manual verification via the human-readable interface.

And that SOAP-based service has been non-functional for almost 24 hours now. It’s not like the WSDL definition is unavailable, although it has produced 404s occasionally. It’s just that any POST requests to that service yield a 500 with the following beautiful stack trace:

org.apache.axis2.AxisFault: The service cannot be found for the endpoint reference (EPR) http://taxudp5.cc.cec.eu.int:7174/taxation_customs/vies/services/checkVatService
	at org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
	at org.apache.axis2.engine.Phase.invoke(Phase.java:333)
	at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:264)
	at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:163)
	at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
	at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
	at cec.taxud.fiscalis.vies.viesweb.web.servlet.Axis2FilterServlet.service(Axis2FilterServlet.java:49)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072)
	at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
	at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
	at cec.taxud.fiscalis.vies.viesweb.api.CheckVatServiceHTTPFilter.doFilter(CheckVatServiceHTTPFilter.java:172)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
	at cec.taxud.fiscalis.vies.viesweb.util.EncodingFilter.doFilter(EncodingFilter.java:26)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6987)
	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
	at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
	at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892)
	at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766)
	at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
	at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)

Looks like someone either totally forgot about making that backend service highly available, or messed up their load balancer, or is monitoring their endpoints incorrectly. Not fun.

But fear not, there is actually an email address posted on the EC’s web site where you can notify people of the problem. Alas, no response there at all in over 12 hours. No autoreply, no “thanks, we’re working on it”, nothing. Maybe it’s because of this priceless statement (found here):

Please note that the European Commission’s offices will be closed from 23 December 2011 to 2 January 2012 inclusive. Your question will therefore not be handled before 3 January 2012.
Thank you for your understanding.

(Emphasis in original). Fun, eh?

Just so you know: our company has no affiliation with my old employer

When we announced the launch of hastexo back in October, I thought that it was quite clear that our new company had no connection with my previous employer. It appears as if to some, in fact that was not as clear as we had anticipated.

So I’ll reiterate, at their request: LINBIT is not affiliated with, invested in, or otherwise connected to hastexo in any way. We’re definitely not a spin-off. We continue to be part of the same open-source community, but there is no corporate connection whatsoever.

I hope that makes it clearer. By the way, their name is a registered trademark.

Announcing hastexo High Availability Expert training: Your chance to be a cluster ace!

We’ve just announced our new training format, hastexo High Availability Expert. If you’re an experienced high-availability engineer and you want to learn how to become a true top-notch clustering expert, this is for you.

Twitter

Henceforth, you can find and follow us on Twitter. See you there!

Busy weeks ahead!

I’m speaking at Percona Live, LinuxCon Europe, and linux.conf.au. And I just co-founded a new company.