배경

Server scale-up 이후부터 Web Application을 배포하고 나면 몇시간 이내에 특정 서버의 CPU 사용률이 100%에 이르는 사태가 발생하였다. thread dump를 확인해 봐도 특별한 이상 징후는 발견되지 않았다. 단지 아래와 같이 여러 Thread 들이 java.util.WeakHashMap.get(WeakHashMap.java:355) 에 걸려있었으나, Thread.State가 RUNNABLE 이기 때문에 주의깊게 보지 않았다. 왜냐하면 지금까지 Java core package에서 문제가 발생한 적은 한 번도 없거니와, Java core package를 의심하게 되면 밑도끝도 없이 모든것을 의심해야 하는 불상사가 발생하기 때문이다. 난 적어도 절친은 믿고 세상을 살아간다. 훗날 내 뒤통수를 칠 지언정…

"TP-Processor233" daemon prio=10 tid=0x8d848800 nid=0x717d runnable [0x893f6000]
   java.lang.Thread.State: RUNNABLE
	at java.util.WeakHashMap.get(WeakHashMap.java:355)
	at com.thoughtworks.xstream.io.xml.XmlFriendlyReplacer.unescapeName(XmlFriendlyReplacer.java:118)
	at com.thoughtworks.xstream.io.xml.AbstractXmlReader.unescapeXmlName(AbstractXmlReader.java:42)
	at com.thoughtworks.xstream.io.xml.AbstractPullReader.getNodeName(AbstractPullReader.java:199)
	at com.thoughtworks.xstream.io.ReaderWrapper.getNodeName(ReaderWrapper.java:44)
	at com.thoughtworks.xstream.io.path.PathTrackingReader.moveDown(PathTrackingReader.java:38)
	at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:199)
	at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
	at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
	at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
	at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
	at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshallField(AbstractReflectionConverter.java:246)
	at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:218)
	at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
	at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
	at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
	at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
	at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
	at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:137)
	at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:33)
	at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:923)
	at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:909)
	at com.thoughtworks.xstream.XStream.fromXML(XStream.java:861)

문제가 된 web application에서 사용하는 XStream의 version이 1.3인데, 혹시나 하는 마음에 공식 XStream site에 들어가서 change history를 보다가 XSTR-584: Race condition in XmlFriendlyReplacer issue를 발견했다. Issue description 에는 내가 겪은 증상과 동일했고, 문제의 원인은 not synchronized java.util.WeakHashMap 을 사용했기 때문이라고 간단히 쓰여 있었다.

com.thoughtworks.xstream.io.xml.XmlFriendlyReplacer makes use of 2 WeakHashmaps to hold string.
Those maps are accessed multi-threaded, but are not synchronized.

This can lead to access on those maps occupying all CPU-resources, which can only get solved by restarting the VM.
This happens under rare heavily multi-threaded circumstances, nevertheless the impact is critical.

Implementation of java.util.Map이 가진 잠재적 문제점

구글링을 해보니 Multi-threaded situation(under high concurrency) 에서 Implementation of java.util.Map 의 get() 호출 시 method 내부에서 infinite loop에 빠질 수 있다고 한다. 해당 되는 Implementation of java.util.Map 는 API Document에 아래와 같이 설명된 Class 들이다.

Note that this implementation is not synchronized. If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be “wrapped” using the Collections.synchronizedMap method. This is best done at creation time, to prevent accidental unsynchronized access to the map:

Map m = Collections.synchronizedMap(new HashMap(…));

• java.util.HashMap
• java.util.LinkedHashMap
• java.util.TreeMap
• java.util.WeakHashMap

더욱이 문제는 대부분의 개발자들은 concurrency로 인한 data corruption 을 염두해두고 위 Class들을 자주 사용한다는 점이다. 즉 개발자가 Java Document의 “Note that this implementation is not synchronized” 의 의미를 race condition 에 의한 data corruption 까지만 이해하고 위 Class들을 자주 사용할수록, infinite loop에 빠질 확률이 더 높아진다.

그 결과 JVM hanging 뿐만 아니라 해당 서버에서 제공하는 서비스들(i.e daemon)까지도 CPU 자원을 사용할 수 없기 때문에 문제는 더욱 커진다. 이렇게 불시에 찾아와 CPU 자원을 모두 고갈시키는 불청객의 위험이 우리 주위에 도사리고 있다.

어느 CS 전공자가 위 Note만 보고 JVM이 hanging 될꺼라 예상할 수 있을까? 5년 넘게 Java language 의 API들을 많이 사용해 왔지만, 위 처럼 황당한 경우는 처음이다. 최소한 infinite loop 에 대한 경고는 해야 하지 않았을까? Synchronization에 따른 deadlock은 들어 봤어도, not synchronization에 따른 infinite loop는 들어 본 적이 없다.

언제 infinite loop가 발생하는가?

기가 막히게 제목을 잘 지은 “A Beautiful Race Condition” article 에서 infinite loop가 언제 발생할 수 있는지에 대해 설명이 잘 되어 있다.

java.util.HashMap.transfer() 를 호출하고 난 뒤 Entry[] table의 상태를 그려보았다.

• normal case

• abnormal case

1. 2개 이상의 thread가 Map에 동시에 write할 때 rehash의 조건이 true 이면
2. Map의 어느 bucket의 Entry.next 가 서로를 가리킨다. infinite loop 생성
3. infinite loop Entry가 있는 bucket 을 read 할 때 해당 thread는 hanging

대응 방법

1. java.util.concurrent.ConcurrentHashMap 사용
2. Collections.synchronizedMap method 사용하여 wrapping
3. mutator method 에 접근 할 때 synchronized 처리

The post Implementation of java.util.Map 의 보이지 않는 위험 appeared first on WonderWall.

Jakarta Project 에피소드Ⅰ

ORO의 보이지 않는 위험

조금 먼 옛날 Jakarta Project 저편에…

1996년 1월 23일 JDK 1.0이 세상에 처음 나온 이후 예상과 달리 많은 사람들로부터 관심을 받기 시작한다. 인기가 많아 질수록 언어 스펙 역시 요구가 많아지게 되는데, 그 중에 하나가 불편한 text-processing이었다.

때마침 1999년 Java Language 창시자인 James Gosling과 Open source 수호자인 Brian Behlendorf가 만나서 Jakarta Project를 설립 하고, Jakarta Project에 힘입은 Savarese는 2000년 7월에 Jakarta ORO project를 발족하여 Java Language에서 Regular Expression(정규 표현식)을 사용할 수 있게 하는데…

Jakarta ORO란?

JAVA는 J2SE 1.4 (February 6, 2002)때부터 Regular Expression(정규 표현식)을 지원하기 시작했다. 그러므로 초창기 JAVA는 text-processing이 타 언어에 비해 사용이 불편했다. 2000년 7월 23일 ORO(Original Reusable Objects) company가 JAVA에서 Regular Expression을 사용할 수 있도록 하기 위해 Set of text-processing Java classes를 Jakarta project에 기증하였다. 그 project가 바로 ORO project이다.

Jakarta ORO가 가진 잠재적 문제점

ORO project는 2003년 12월 30일 마지막 release이후, 많은 개발자로부터 J2SE 1.4에 포함된 JAVA CORE regular expression package(java.util.regex)에 비해서 현저히 떨어지는 성능과 높은 메모리 사용률에 대한 개선 요구사항들이 쇄도하게 된다. 이에 대해 original code contributor인 Daniel Savarese는 J2SE 1.4 이후 추가된 java.lang.CharSequence를 사용하면 위 언급한 성능/메모리에 대한 요구사항을 만족시킬 수는 있지만, backward compatibility(J2SE 1.4 이전 하위 호환성) 문제 때문에 요구사항을 들어줄 수 없었다고 한다.

그러므로 org.apache.oro package는 Perl5/AWK-like compatible regular expression을 사용할 수 있다는 장점이 있으나, java core regular expression package에 비해 현저히 떨어지는 성능과 높은 메모리 사용률이라는 단점 때문에 이를 감수하면서 사용할 경우, 언제 running service에 장애가 발생할 지 모른다.

더 큰 문제는 J2SE 1.4 이전에 개발 시작한 open source가 ORO package를 많이 사용하고 있으며, 특히 Jakarta subproject 상당수가 ORO package를 사용하고 있는 실정이란 점이다.

대응 방법

ORO package에 dependent한 대표적 open source인 spring framework, Jakarta ant 그리고 json-lib가 어떻게 ORO package를 사용하고 있는지 살펴봤다.

Json-lib와 spring framework는 JAVA version 1.4를 기준으로 ORO에 binding할지 Java core regular expression에 binding할지를 결정한다. 그러므로 version 1.4 이후의 JAVA를 사용하면 ORO에 binding되지 않기 때문에 ORO의 잠재적 문제로부터 안전하다.

한편 Jakarta ant는 default로 Java core regular expression에 binding되기 때문에 애초부터ORO의 잠재적 문제로부터 벗어날 수 있다. (jakarta ant는 property설정으로 jakarta ORO, Jakarta Regexp, Java core regular expression중 하나를 선택하여 사용하는 구조임)

위 3가지 open source 조사결과로 미루어 볼 때, ORO는 backward compatibility를 제공하는데 주로 사용되며 version 1.4 이후의 JAVA를 사용할 경우에는 ORO에 binding되지 않을 것이라 추측한다. 왜냐하면 2002년 JAVA version 1.4가 release된 이후 open source는 많은 사람들로부터 오랜 기간 동안 사용되면서 충분히 검증 받은 code라고 생각하기 때문이다. 하지만 직접 눈으로 확인하는 것이 가장 확실한 방법이다.

정리하면,

• The latest stable version of JAVA(가장 최신의 안정버전)를 사용한다.
• 규모가 작은 open source일 경우 직접 눈으로 확인한다.

대응 방법 예시 (직접 눈으로 source code 검증)

1. json-lib (version 2.2.2)
   • source code > net.sf.json.regexp.RegexpUtils.java

   package net.sf.json.regexp;
   
   public class RegexpUtils {
   …
   (중간 생략)
   …
   
      /**
       * Returns a RegexpMatcher that works in a specific environment.
   
       * When in a JVM 1.3.1 it will return a Perl5RegexpMatcher, if the JVM is
       * younger (1.4+) it will return a JdkRegexpMatcher.
       */
      public static RegexpMatcher getMatcher( String pattern ) {
         if( isJDK13() ){
            return new Perl5RegexpMatcher( pattern );
         }else{
            return new JdkRegexpMatcher( pattern );
         }
      }
   
   …
   (중간 생략)
   …
   }
   

   • Inheritance diagram

   

2. spring framework (version 2.0.6)
   • source code > org.springframework.aop.support.RegexpMethodPointcutAdvisor.java

   package org.springframework.aop.support;
   …
   (중간 생략)
   …
   
   public class RegexpMethodPointcutAdvisor extends AbstractGenericPointcutAdvisor {
   
   …
   (중간 생략)
   …
   
   	/**
   	 * Create the actual pointcut: By default, a {@link Perl5RegexpMethodPointcut}
   	 * will be created if Perl5 syntax is enforced or when running on JDK 1.3.
   	 * Else, a {@link JdkRegexpMethodPointcut} (JDK 1.4+) will be used.
   	 * @return the Pointcut instance (never <code>null</code>)
   	 * @see #setPerl5
   	 * @see Perl5RegexpMethodPointcut
   	 * @see JdkRegexpMethodPointcut
   	 */
   	protected AbstractRegexpMethodPointcut createPointcut() {
   		if (this.perl5 || JdkVersion.getMajorJavaVersion() < JdkVersion.JAVA_14) { 
   			// needs Jakarta ORO on the classpath 
   			return Perl5RegexpPointcutFactory.createPerl5RegexpPointcut(); 
   		} else { 
   			// needs to run on JDK >= 1.4
   			return new JdkRegexpMethodPointcut();
   		}
   	}
   
   …
   (중간 생략)
   …
   }
   

   • Inheritance diagram

   

3. Jakarta Ant (version 1.8)
   • source code > org.apache.tools.ant.util.regexp.RegexpFactory.java

   package org.apache.tools.ant.util.regexp;
   …
   (중간 생략)
   …
   public class RegexpFactory extends RegexpMatcherFactory {
   …
   (중간 생략)
   …
      /**
       * Create a new regular expression matcher instance.
       * Available implementations:
       *
       *   org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp (default)
       *        Based on the JDK's built-in regular expression package
       *
       *   org.apache.tools.ant.util.regexp.JakartaOroRegexp
       *        Based on the jakarta-oro package
       *
       *   org.apache.tools.ant.util.regexp.JakartaRegexpRegexp
       *        Based on the jakarta-regexp package
       *
       * @param p Project whose ant.regexp.regexpimpl property will be used.
       * @return the matcher instance
       * @throws BuildException on error
       */
       public Regexp newRegexp(Project p) throws BuildException {
           String systemDefault = null;
           if (p == null) {
               systemDefault = System.getProperty(MagicNames.REGEXP_IMPL);
           } else {
               systemDefault = p.getProperty(MagicNames.REGEXP_IMPL);
           }
   
           if (systemDefault != null) {
               return createRegexpInstance(systemDefault);
               // XXX     should we silently catch possible exceptions and try to
               //         load a different implementation?
           }
   
           return new Jdk14RegexpRegexp();//         default
       }
   …
   (중간 생략)
   …
   
   }
   

   • Inheritance diagram

   

The post Jakarta Project 에피소드 Ⅰ: ORO의 보이지 않는 위험 appeared first on WonderWall.