About Vlad Mihalcea

Vlad Mihalcea is a software architect passionate about software integration, high scalability and concurrency challenges.

The regex that broke a server

I’ve never thought I would see an unresponsive server due to a bad regex matcher but that’s just happened to one of our services, yielding it it unresponsive.

Let’s assume we parse some external dealer car info. We are trying to find all those cars with “no air conditioning” among various available input patterns (but without matching patterns such as “mono air conditioning”).

The regex that broke our service looks like this:
 
 
 

String TEST_VALUE = "ABS, traction control, front and side airbags, Isofix child seat anchor points, no air conditioning, electric windows, \r\nelectrically operated door mirrors";
double start = System.nanoTime();
Pattern pattern = Pattern.compile("^(?:.*?(?:\\s|,)+)*no\\s+air\\s+conditioning.*$");
assertTrue(pattern.matcher(TEST_VALUE).matches());
double end = System.nanoTime();
LOGGER.info("Took {} micros", (end - start) / (1000 ));

After 2 minutes this test was still running and one CPU core was fully overloaded.

regex-overload

First, the matches method uses the entire input data, so we don’t need the start(^) or the end($) delimiters, and because of the new line characters in the input string we must instruct our Regex Pattern to operate in a MULTILINE mode:

Pattern pattern = Pattern.compile("(?:.*?(?:\\s|,)+)*no\\s+air\\s+conditioning.*?", Pattern.MULTILINE);

Let’s see how multiple versions of this regex behave:

RegexDuration [microseconds]Observation
“(?:.*?(?:\\s|,)+)*no\\s+air\\s+conditioning.*?”35699.334This is way too slow
“(?:.*?(?:\\s|,)+)?no\\s+air\\s+conditioning.*?”108.686The non-capturing group doesn’t need the one-or-many(+) multiplier, so we can replace it with zero-or-one(?)
“(?:.*?\\b)?no\\s+air\\s+conditioning.*?”153.636It works for more input data than the previous one, which only uses the space(\s) and the comma(,) to separate the matched pattern
“\\bno\\s+air\\s+conditioning”78.831Find is much faster than matches and we are only interested in the first occurrence of this pattern.

Why not using String.indexOf() instead?

While this would be much faster than using regex, we would still have to consider the start of the string, patterns such as “mono air conditioning”, tabs or multiple space characters between our pattern tokens. Custom implementations as such may be faster, but are less flexible and take more time to implement.

Conclusion

Regex is a fine tool for pattern matching, but you must not take it for granted since small changes may yield big differences. The reason why the first regex was counterproductive is due to catastrophic backtracking, a phenomena that every developer should be aware of before starting writing regular expressions.
 

Reference: The regex that broke a server from our JCG partner Vlad Mihalcea at the Vlad Mihalcea’s Blog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

3 Responses to "The regex that broke a server"

  1. Robby says:

    A great resource for regexp related things: http://swtch.com/~rsc/regexp/

    It specifically talks about the backtrack problem in the first article.

  2. It’s no wonder that regex took down a server.

Leave a Reply


9 × = forty five



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close