On May 14th mybatis.org stopped responding to web requests. After some investigation and working with GoDaddy, we've apparently broken their usage policy for domain hosting due to excessive load against our DTDs. This was a shared hosting arrangement and our usage threatened the QoS for other customers. We've therefore been asked to upgrade our account or move. We've chosen the latter.
Before moving on to solutions, let's quantify this a bit:
There is nothing terribly unusual about our bandwidth profile. If you look at the small chart below, you can easily see a fairly normal pattern of usage, higher during weekdays, lower on the weekends. I think it may have been the one particular Tuesday where things spiked (last bar) that GoDaddy got itchy.
Still, this wasn't like a 10x spike or anything, and our overall usage is 70GB of 300GB / month. So we had no immediate cause for concern. However, GoDaddy is within their right to determine what is acceptable on shared hosting environments.
If you're the curious type, you might wonder how/why the heck we serve 70GB of DTDs every month. This is nothing new, and it was the initial reason for my moving the site to GoDaddy -- it was free and I had expected that their server infrastructure (GoDaddy!) could handle our piddly little open source project. Previously hosting this was costing me money - not a lot - but more than zero, which is around how much money I made from 10 years of working on iBATIS/MyBatis. :-)
Is there anything at all strange about this?
YES. Unfortunately there are a small few who are hitting our site way more than everyone else. There are 260,000 requests coming from one IP address alone. When I hosted this myself, I blocked them with iptables after they did not respond to my inquiries. We don't have such control with the GoDaddy shared hosting arrangement.
Is 260,000 a lot from one IP? Well, yeah, but also no... if you do some quick math, this could easily be 150 developers working at a single company who restart their platform in their IDE an average of 10 times per day.
Or it could be a super active site with 400 servers that they restart every 30 minutes for stability (crazy, but you know it happens -- usually not with Java... but...).
Or it could simply be a common ISP firewall used by 100 different companies with a smaller number of developers and servers each.
Finally, and here's where the solutions for you comes in... it could be bad practices and/or bad tools.
Did your apps crash? Fail to start? IDE not working? Etc?
#1 Bad DOCTYPE
The MyBatis DTDs have always been hosted on mybatis.org, but they've also always been intended to be loaded from the JAR file, not from the site. As long as you use the proper DOCTYPE in your XML file, they should load from the JAR file.
Here's an example of the correct mapper DOCTYPE:
PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
Note the no "www" at the beginning. Anything else, and you might find yourself dependent on mybatis.org. The team has discussed adding the "www" case, but we found that many requests are to mybatis.org, so the next point may be more relevant to many.
#2 Bad XML Parsing Library or conflicting library
We use a standard feature of the Java XML API called "entity resolvers" to load the DTD from the JAR file. Some application servers and IDEs use XML parsers that may not support this feature, and then once again, you become dependent on mybatis.org.
In addition, other advanced container frameworks or dependency injection frameworks or anything that might intercept or rewrite how your XML is handled could be breaking the entity resolver functionality and leaving you dependent on mybatis.org.
The only way to know is to test it. Pull the plug and try it out.
#3 Did your app crash while already running?
This probably means that you're loading your SQL map configs dynamically or more than once within your application. We highly recommend that you always load them once and at startup for the best stability and performance.
As mentioned above, the high-request IP address might very well be one horribly written application.
High Availability is Your Responsibility
Given all of the above, you are responsible for the stability and availability of your app. You have to test for cases like this to ensure that your apps remain available in the event that a freely hosted public internet site that is beyond your control becomes unavailable. :-)
If you require high availability and the entity resolvers don't work for you or you don't trust them, then you can host the DTDs yourself. They are simply two little files you stick on your own internal web infrastructure somewhere, then change the DOCTYPE to load the DTD from there instead. You can even load it from the filesystem using a file:// URL.
You have all the power you need to make your apps stable and independent of 3rd party servers.
The Time is Now
It's a perfect time to get your apps stable, as mybatis.org will likely continue to be down for the rest of today. Our volunteers are working to move the DTDs to new infrastructure which should be more stable.
But in the event of another disaster... be ready.
Creator of iBATIS/MyBatis and host of the DTDs for 10+ years, for which we've been down maybe 2 or 3 times. :-)
You received this message because you are subscribed to the Google Groups "mybatis-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|Free forum by Nabble||Edit this page|