KR101997174B1

KR101997174B1 - 업데이트된 에이전트의 핫 롤백

Info

Publication number: KR101997174B1
Application number: KR1020130101332A
Authority: KR
Inventors: 마르코 가글리아르디
Original assignee: 씨에이, 인크.
Priority date: 2012-08-24
Filing date: 2013-08-26
Publication date: 2019-07-05
Also published as: EP2701060B1; US20140059528A1; EP2701060A1; KR20140026313A; US9817656B2

Abstract

애플리케이션과 관련된 에이전트의 버전을 관리하는 기술이 본 명세서에 개시된다. 상기 에이전트에 대한 코드는 상기 애플리케이션에 손상을 주지 않으면서 업데이트되고 후에 롤백될 수 있다.

Description

업데이트된 에이전트의 핫 롤백{HOT ROLLBACK OF UPDATED AGENT}

본 발명은 자바 가상 머신(Java Virtual Machine: JVM) 및 다른 유사 소프트웨어 환경에서 사용하기 위한 에이전트 기반 기술(agent based technology)에 관한 것이다.

자바(Java)에서, 클래스(class)는 실행될 코드(code)를 나타낸다. 특정 상태가 클래스와 관련될 때, 이 클래스의 인스턴스(instance)가 존재한다. 그래서 동일한 클래스의 상이한 인스턴스들은 상이한 상태를 가질 수 있으나, 일반적으로 동일한 코드를 나타낸다.

소스 파일들( .자바 파일들)은 .클래스 확장자(class extension)를 가지는 (가상) 머신-판독가능한 클래스 파일들로 컴파일된다. 자바는 플랫폼에 독립적인 언어이므로, 소스 코드는 바이트 코드(byte code)로 알려진 출력 파일로 컴파일되어 클래스 파일에 저장된다. 소스 파일이 하나를 초과하는 클래스를 가지는 경우, 각 클래스는 통상적으로 별개의 클래스 파일들로 컴파일된다. JAR 파일 (Java ARchive)은 애플리케이션 소프트웨어 또는 라이브러리를 분배하기 위해 많은 자바 클래스 파일을 결합하는데 일반적으로 사용되는 아카이브 파일 포맷(archive file format)이다. JAR 파일은 ZIP 파일 포맷 상에 형성되고, .jar 파일 확장자를 가지고 있다.

JVM들은 자바 소프트웨어 플랫폼의 코드 실행 성분(code execution component)이다. 클래스 파일은 일반적으로 임의의 JVM에 의해 로딩될 수 있다. JVM은 많은 플랫폼에서 이용가능하고, 하나의 플랫폼을 위해 컴파일된 클래스 파일은 다른 플랫폼의 JVM에서 실행되어야 한다. 이것은 자바를 플랫폼과 독립적이게 한다.

자바 클래스로더(Java Classloader)는 자바 클래스를 JVM에 동적으로 로딩하는 자바 실행시간 환경(Java Runtime Environment)의 일부이다. 통상적으로, 클래스는 요구시에만 로딩된다. JVM이 시작될 때, 3개의 클래스로더, 즉 부트스트랩 클래스로더(Bootstrap Classloader), 확장자 클래스로더(Extensions Classloader) 및 시스템 클래스로더(System Classloader)가 사용된다. 부트스트랩 클래스로더는 코어 자바 라이브러리(core Java libraries)를 로딩한다.

자바 인스트루먼테이션 API(Java Instrumentation API)는 자바 프로그래밍 언어 에이전트가 JVM에서 실행되는 프로그램을 인스트루먼트(instrument)하거나 이 프로그램에서 동작하는 수단을 제공한다. 하나의 인스트루먼트 메커니즘은 자바 클래스 파일의 메소드(methods)의 바이트 코드의 변경(modification)이다. 에이전트는 JAR 파일 (agent.jar 파일)로 전개(deployed)된다. JAR 파일 매니페스트(manifest)의 속성은 에이전트를 시작하기 위해 로딩될 수 있는 에이전트 클래스를 지정한다. 명령-라인 인터페이스(command-line interface)를 지원하는 구현을 위해, 에이전트는 명령-라인에 옵션(option)을 지정하는 것에 의해 시작된다. 구현은 또한 JVM이 시작된 후에 에이전트를 개시하는 메커니즘을 지원할 수 있다. 예를 들어, 구현은 실행 애플리케이션(running application)에 도구를 부착하고 이 실행 애플리케이션으로 도구의 에이전트의 로딩을 개시하는 메커니즘을 제공할 수 있다.

명령-라인 인터페이스로 구현시에, 에이전트는 이하의 옵션을 명령-라인에 추가하는 것에 의해 시작된다:

-javaagent:jarpath[=options]

상기 명령 라인 옵션에서, jarpath(jar경로)는 에이전트의 JAR 파일로의 경로이고 옵션(options)은 에이전트 옵션이다. 이 스위치는 동일한 명령-라인에 다수회 사용되어, 다수의 에이전트를 생성할 수 있다. 하나를 초과하는 에이전트가 동일한 jar경로를 사용할 수 있다. 에이전트의 JAR 파일은 JAR 파일 사양에 순응해야 한다.

에이전트의 JAR 파일의 매니페스트는 속성 프리메인-클래스(attribute Premain-Class)를 포함한다. 이 속성의 값은 에이전트 클래스의 네임(name)이다. 에이전트 클래스는 메인 애플리케이션의 진입점과 원리적으로 유사한 퍼블릭 스테틱(public static) "프리메인" 메소드를 구현한다. JVM이 초기화된 후에, 각 "프리메인" 메소드는 에이전트들이 지정한 순서로 호출되고 나서 실제 애플리케이션의 메인 메소드가 호출된다. 에이전트 클래스는 부트스트랩 클래스로더에 의해 로딩되고, 이는 에이전트의 JAR 파일을 록킹(lock)하여 에이전트의 JAR 파일에 있는 코드를 정상적으로는 변경될 수 없게 한다.

본 발명의 일 양상에 따르면, 에이전트의 버전(versions)을 관리하는 기술이 개시된다. 일 실시예는 자바 가상 머신(또는 다른 소프트웨어 환경)의 애플리케이션으로 에이전트를 실행하는 단계, 애플리케이션과 자바 가상 머신(또는 다른 소프트웨어 환경)이 계속 실행되는 동안 에이전트에 대한 이전의 코드 버전을 사용하기 위해 에이전트를 롤백(rolling back)하는 단계, 및 롤백된 에이전트를 자바 가상 머신의 애플리케이션으로 실행하는 단계를 포함한다.

일 실시예는 애플리케이션이 실행되고 있는 동안 애플리케이션으로 에이전트를 실행하는 단계, 에이전트에 대한 식별된 코드 소스를 록킹하는 단계, 에이전트에 대한 식별된 코드 소스가 록킹된 동안 에이전트에 대한 코드를 업데이트(update)하는 단계, 업데이트된 에이전트를 애플리케이션으로 실행하는 단계, 에이전트에 대한 식별된 코드 소스가 록킹된 동안 에이전트에 대한 이전의 코드 버전을 사용하기 위해 에이전트를 롤백하는 단계, 및 롤백된 에이전트를 상기 애플리케이션으로 실행하는 단계를 포함한다.

본 개요는 이하 상세한 설명에 후술되는 내용 중 선택적 개념을 간략한 형태로 소개하려고 제공된 것이다. 본 개요는 본 발명의 주제의 주요 특징이나 핵심 특징을 식별하려고 의도된 것이 아닐 뿐만 아니라, 본 발명의 주제의 범위를 결정하는 것을 보조하는 것으로 사용하려고 의도된 것도 전혀 아니다. 본 발명의 주제는 배경 기술에 언급된 임의의 단점이나 모든 단점을 해결하는 구현으로 제한되는 것은 아니다.

도 1은 애플리케이션을 위한 에이전트의 버전을 관리하는 프로세스의 일 실시예를 기술하는 흐름도.
도 2는 에이전트를 사용할 수 있는 시스템의 일 실시예를 기술하는 블록도.
도 3은 전개된 에이전트를 가지는 시스템의 일 예를 도시하는 블록도.
도 4는 에이전트의 버전을 사용하고 관리할 수 있는 자바 시스템의 컴포넌트들의 일 예를 도시하는 블록도.
도 5는 JVM에서 실행되는 애플리케이션을 위한 에이전트를 전개하는 프로세스의 일 실시예를 기술하는 흐름도.
도 6은 애플리케이션과 에이전트를 실행하는 프로세스의 일 실시예를 기술하는 흐름도.
도 7a 및 도 7b는 에이전트를 업데이트하는 프로세스의 일 실시예를 함께 기술하는 흐름도.
도 8은 에이전트에 대한 이전의 코드 버전을 사용하기 위해 에이전트를 롤백시키는 프로세스의 일 실시예를 기술하는 흐름도.
도 9는 에이전트를 업데이트시키는 프로세스의 다른 실시예의 일부를 기술하는 흐름도.
도 10은 도 9의 프로세스와 함께 에이전트를 롤백시키는 프로세스의 일 실시예를 기술하는 흐름도.
도 11은 본 명세서에 설명된 기술과 사용하기 위한 적절한 컴퓨팅 디바이스의 일례의 블록도.

이 기술 분야에 통상의 지식을 가진 자라면 이해할 수 있는 바와 같이, 본 발명의 양상들은 본 명세서에서 임의의 신규하고 유용한 프로세스, 머신, 제조물 또는 조성물, 또는 이들의 임의의 신규하고 유용한 개선을 포함하는 다수의 특허가능한 클래스 또는 컨텍스트(context) 중 어느 것으로 도시되고 기술될 수 있다. 따라서, 본 발명의 양상들은 모두 본 명세서에서 일반적으로 "회로", "모듈", "컴포넌트" 또는 "시스템"이라고 언급될 수 있는, 완전히 하드웨어로, 완전히 소프트웨어(펌웨어, 상주하는 소프트웨어, 마이크로코드 등을 포함하는)로, 또는 소프트웨어와 하드웨어 구현을 결합하여 구현될 수 있다. 나아가, 본 발명의 양상들은 컴퓨터 판독가능한 프로그램 코드를 저장한 하나 이상의 컴퓨터 판독가능한 매체로 구현된 컴퓨터 프로그램 제품의 형태를 취할 수 있다.

하나 이상의 컴퓨터 판독가능한 매체의 임의의 조합이 사용될 수 있다. 컴퓨터 판독가능한 매체는 컴퓨터 판독가능한 신호 매체 또는 컴퓨터 판독가능한 저장 매체일 수 있다. 컴퓨터 판독가능한 저장 매체는 예를 들어 전자, 자기, 광, 전자기, 또는 반도체 시스템, 장치, 또는 디바이스, 또는 이들의 임의의 적절한 조합일 수 있으나, 이들로 제한되지 않는다. 컴퓨터 판독가능한 저장 매체의 보다 구체적인 예(전부 다 나열한 것이 아닌 리스트)로는 휴대용 컴퓨터 디스켓, 하드 디스크, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 소거가능한 프로그래밍가능한 판독 전용 메모리(EPROM 또는 플래시 메모리), 리피터(repeater)를 구비하는 적절한 광섬유, 휴대용 콤팩트 디스크 판독 전용 메모리(CD-ROM), 광 저장 디바이스, 자기 저장 디바이스, 또는 이들의 임의의 적절한 조합을 포함할 수 있다. 이 문헌의 상황에서, 컴퓨터 판독가능한 저장 매체는 인스트럭션 실행(instruction execution) 시스템, 장치, 또는 디바이스에 의해 또는 이와 함께 사용하기 위한 프로그램을 포함하거나 저장할 수 있는 임의의 유형적인 매체일 수 있다.

컴퓨터 판독가능한 신호 매체는 예를 들어, 기저대역에 또는 반송파의 일부로 컴퓨터 판독가능한 프로그램 코드를 구비하는 전파된(propagated) 데이터 신호를 포함할 수 있다. 이러한 전파된 신호는 전자기, 광, 또는 이들의 임의의 적절한 조합을 포함하나 이들로 제한되지 않는 여러 형태 중 어느 것을 취할 수 있다. 컴퓨터 판독가능한 신호 매체는 인스트럭션 실행 시스템, 장치, 또는 디바이스에 의해 또는 이와 함께 사용하기 위한 프로그램을 통신, 전파, 또는 전송할 수 있는, 컴퓨터 판독가능한 저장 매체가 아닌 임의의 컴퓨터 판독가능한 매체일 수 있다. 컴퓨터 판독가능한 신호 매체 상에 구현된 프로그램 코드는 와이어리스(wireless), 와이어라인(wireline), 광섬유 케이블, RF 등 또는 이들의 임의의 적절한 조합을 포함하나 이들로 제한되지 않는 임의의 적절한 매체를 사용하여 전송될 수 있다.

본 발명의 양상에 대한 동작을 수행하기 위한 컴퓨터 프로그램 코드는 Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, CII, VB.NET, Python 등과 같은 객체 지향 프로그래밍 언어; "c" 프로그래밍 언어, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP와 같은 종래의 절차적 프로그래밍 언어; Python, Ruby 및 Groovy와 같은 동적 프로그래밍 언어; 또는 다른 프로그래밍 언어를 포함하는 하나 이상의 프로그래밍 언어의 임의의 조합으로 기록될 수 있다. 프로그램 코드는 완전히 유저의 컴퓨터에서 실행되거나, 부분적으로 유저의 컴퓨터에서 실행되거나, 독립형 소프트웨어 패키지로서 실행되거나, 부분적으로 유저의 컴퓨터에서 실행되고 부분적으로 원격 컴퓨터에서 실행되거나, 또는 완전히 원격 컴퓨터 또는 서버에서 실행될 수 있다. 후자의 시나리오에서, 원격 컴퓨터는 LAN(local area network) 또는 WAN(wide area network)을 포함하는 임의의 유형의 네트워크를 통해 유저의 컴퓨터에 연결될 수 있고, 또는 이 연결은 외부 컴퓨터 (예를 들어, 인터넷 서비스 제공자를 사용하여 인터넷을 통해) 또는 클라우드 컴퓨팅 환경에서 이루어질 수 있거나 또는 SaaS(Software as a Service)와 같은 서비스로 제공될 수 있다.

본 발명의 양상들은 본 발명의 실시예에 따른 방법, 장치(시스템) 및 컴퓨터 프로그램 제품의 흐름도 및/또는 블록도를 참조하여 본 명세서에 설명된다. 흐름도 및/또는 블록도의 각 블록과, 이 흐름도 및/또는 블록도에서 블록의 조합은 컴퓨터 프로그램 인스트럭션에 의해 구현될 수 있는 것으로 이해된다. 이 컴퓨터 프로그램 인스트럭션은 일반 목적 컴퓨터(general purpose computer), 특수 목적 컴퓨터(special purpose computer), 또는 다른 프로그래밍가능한 데이터 프로세싱 장치의 프로세서에 제공되어, 이 인스트럭션이, 컴퓨터 또는 다른 프로그래밍가능한 인스트럭션 실행 장치의 프로세서를 통해 실행될 때 흐름도 및/또는 블록도의 블록 또는 블록들에 지정된 기능/동작을 구현하는 메커니즘을 야기하는 머신을 생성하도록 구성될 수 있다.

이 컴퓨터 프로그램 인스트럭션은 또한 컴퓨터 판독가능한 매체에 저장될 수 있고, 이 인스트럭션은, 실행될 때, 컴퓨터, 다른 프로그래밍가능한 데이터 프로세싱 장치, 또는 다른 디바이스에 특정 방식으로 기능하도록 지시하여, 컴퓨터 판독가능한 매체에 저장될 때의 인스트럭션이 실행될 때 컴퓨터로 하여금 흐름도 및/또는 블록도의 블록 또는 블록들에 지정된 기능/동작을 구현하게 하는 인스트럭션을 포함하는 제조 물품을 생성하도록 구성될 수 있다. 컴퓨터 프로그램 인스트럭션은 또한 컴퓨터, 다른 프로그래밍가능한 인스트럭션 실행 장치, 또는 다른 디바이스 상에 로딩되어 일련의 동작 단계들이 컴퓨터, 다른 프로그래밍가능한 장치 또는 다른 디바이스 상에 수행될 수 있게 하여 컴퓨터 또는 다른 프로그래밍가능한 장치에서 실행되는 인스트럭션이 흐름도 및/또는 블록도의 블록 또는 블록들에 지정된 기능/동작을 구현하는 프로세스를 제공하는 컴퓨터로 구현된 프로세스를 생성하도록 구성될 수 있다.

JVM에서 실행되는 자바 애플리케이션을 위한 에이전트와 같은 에이전트의 버전을 관리하는 기술이 본 명세서에 개시된다. 이 에이전트는 에이전트(예를 들어, 에이전트 jar 파일)에 대한 식별된 코드 소스와 관련된다. 에이전트에 대한 코드는, 에이전트에 대한 코드 소스가 록킹된 동안, JVM이 실행되고 있는 동안 및/또는 애플리케이션이 실행되고 있는 동안, 업데이트되고 나서 안전하게 롤백될 수 있다.

도 1은 애플리케이션을 위한 에이전트의 버전을 관리하는 하이 레벨 프로세스의 일 실시예를 기술하는 흐름도이다. 블록(102)에서, 소프트웨어 환경이 론칭(launchd)된다. 예를 들어, 애플리케이션이 자바 프로그래밍 언어로 기록되어 있다면, 블록(102)은 자바 실행시간 환경을 론칭하는 단계 및/또는 론칭하는 단계를 포함할 수 있다. 블록(104)에서, 애플리케이션과 함께 사용될 에이전트가 론칭된다. 블록(106)에서, 이 에이전트에 대한 코드가 록킹된다. 예를 들어, 이 코드가 파일에 저장되어 있다면, 이 파일은 다른 프로세스가 이 파일의 코드에 액세스하거나 및/또는 이를 변경하는 것을 방지하도록 록킹될 수 있다. 블록(108)에서, 애플리케이션이 론칭된다. 블록(110)에서, 애플리케이션과 에이전트는 블록(102)에서 론칭된 소프트웨어 실시예 내에서 모두 실행된다. 일부 실시예에서, 애플리케이션은 에이전트에 앞서 론칭되거나 에이전트와 동시에 론칭될 수 있다.

블록(112)에서, 에이전트는 에이전트에 대한 코드가 록킹되어 유지되는 동안 업데이트된다(블록(106) 참조). 추가적으로, 애플리케이션과 소프트웨어 환경은 에이전트가 업데이트되는 동안 계속 실행된다. 예를 들어, 에이전트는 애플리케이션 또는 소프트웨어 환경을 중지(stop)시키거나 재시작(restart)함이 없이 업데이트될 수 있다. 블록(110)과 블록(112) 사이의 화살표는 이들 2개의 블록이 서로 직후에 일어나지 않을 수 있고 많은 다른 기능이 이들 2개의 블록들 사이에 일어날 수 있다는 것을 나타내기 위해 대시 라인으로 도시되어 있는 것으로 이해된다. 블록(114)에서, 시스템은 업데이트된 에이전트와 함께 애플리케이션을 계속 실행한다. 블록(116)에서, 업데이트된 에이전트에 문제가 있는 것으로 결정된다. 그리하여, 블록(118)에서, 에이전트는, 애플리케이션을 계속 실행하면서 (즉, 애플리케이션을 중지하거나 애플리케이션을 재시작함이 없이), 및 소프트웨어 환경을 계속 실행하면서 (즉, 소프트웨어 환경을 중지하거나 및/또는 재시작함이 없이), 에이전트에 대한 이전의 코드 버전을 사용하기 위해 롤백된다.

도 2는 본 명세서에 설명된 바와 같이 에이전트를 사용할 수 있는 시스템의 일 실시예를 도시하는 블록도이다. 도 2는 이 기술 분야에 알려진 표준 애플리케이션 서버인 애플리케이션 서버(200)를 도시한다. 대안적인 실시예에서, 애플리케이션 서버(200)는 부하가 균형잡힌 다수의 애플리케이션 서버, 하나 이상의 웹 서버와 함께 하나 이상의 애플리케이션 서버, 또는 다른 유형의 서버를 포함할 수 있다. 애플리케이션 서버(200)는 애플리케이션을 구현하는데 사용되는 코드인 애플리케이션 코드(202)를 수신한다. 애플리케이션 서버(200)는 에이전트를 구현하는 코드를 포함하는 에이전트 코드(204)를 더 수신할 수 있다. 일 실시예에서, 에이전트 코드(204)는 변환기(transformer)(206)를 구현하는 코드, 에이전트심(AgentShim)(208)을 구현하는 코드, 및 에이전트 클래스(Agent Class)(210)를 구현하는 코드를 포함한다. 일 실시예에서, 심(shim)은 기능(예를 들어, 메소드, 절차 등)의 호출(invocation)을 인터셉트(intercept)하거나 수신하고 이 이 호출을 다른 곳으로 재지향(redirect)시키는 코드 유닛(unit)이다. 에이전트심(208)의 추가적인 상세는 아래에 제공된다.

일 실시예에서, 본 명세서에 설명된 기술은 자바 실행시간 환경에서 전개될 수 있다. 그러나, 본 명세서에 설명된 기술은 자바에 더하여 다른 소프트웨어 환경에서 사용될 수 있다. 도 3은 자바 실행시간 환경에서 전개된 에이전트를 가지는 시스템의 일례를 도시하는 블록도이다. 도 3의 시스템은 도 2의 에이전트 코드(204) (및/또는 다른 코드)의 변환기(206)가 JVM 내에서 실행되는 관리되는 애플리케이션을 생성하는 애플리케이션(애플리케이션 코드(202))을 인스트루먼트하는데 사용되는 것을 가정한다. 그리하여, 도 3은 JVM(250)을 구현하는 애플리케이션 서버(200)를 도시한다. JVM(250) 내에서 실행되는 것은 관리되는 애플리케이션(252)이다. 관리되는 애플리케이션(252)을 위한 애플리케이션 코드(202)는 에이전트(256)의 여러 메소드를 호출하는 프로브(probe)(254)를 포함하도록 인스트루먼트된다. 에이전트(256)는 도 2의 에이전트 코드(204)를 사용하여 구현되는 것으로 이해된다. 일 실시예에서, 에이전트(256)는 관리되는 애플리케이션(252)의 성능을 모니터링하고, 성능 데이터를 관리자(manager)(280)에 송신하는데 사용될 수 있고, 이 관리자는 성능 데이터를 데이터 저장소(282)에 저장할 수 있다. 에이전트(256)는 인터넷, LAN, WAN, 와이어리스 또는 다른 유형의 네트워크를 포함할 수 있는 하나 이상의 네트워크(270)를 통해 관리자(280)와 통신할 수 있다. 도 3의 구성에서 관리되는 애플리케이션과 에이전트를 포함하는 시스템의 추가적인 상세는 전체 내용이 본 명세서에 참조 문헌으로 병합된, 미국 특허 번호 7,225,361; 미국 특허 번호 7,234,080; 미국 특허 번호 7,310,777; 및 미국 특허 번호 7,870,431에서 찾아볼 수 있다.

성능 모니터링과는 다른 기능을 수행하는 에이전트가 또한 본 명세서에 설명된 기술에 사용될 수 있다. 에이전트에 특정 기능이 요구되지는 않는다. 일 실시예에서, 에이전트는 자바 인스트루먼테이션 API의 -javaagent(자바에이전트) 옵션을 이용하는 어떤 것(anything)일 수 있다. 이러한 실시예에서, 에이전트에 대한 클래스 파일은 jar 파일에 저장될 수 있다. 다른 실시예에서, 에이전트는 제3 프로세스를 대신하여 다른 프로세스를 관리하거나 또는 제3 프로세스를 대신하여 동작하는 프로세스일 수 있다.

전술된 바와 같이, 에이전트의 버전을 관리하는 기술이 본 명세서에 제공된다. 이 점에서, 도 3은 JVM(250) 외부에서 또는 JVM(250) 내부에서 실행되는 소프트웨어일 수 있는 업데이트 관리자(260)를 도시한다. 업데이트 관리자(260)는 JVM(250) 및/또는 관리되는 애플리케이션(252)을 계속 실행하면서 (즉, JVM(250) 및/또는 관리되는 애플리케이션(252)을 중지하거나 및/또는 재시작해야 함이 없이) 에이전트(256)로 하여금 업데이트되거나 롤백될 수 있게 하는데 사용될 수 있다. 도 3은 에이전트(256)를 업데이트하는데 사용될 수 있는 업데이트된 에이전트 코드(290)를 더 도시한다. 일 실시예에서, 업데이트된 에이전트 코드(290)는 새로운 변환기, 새로운 에이전트심, 및/또는 새로운 에이전트 클래스를 포함한다.

도 4는 에이전트(256)를 업데이트하거나 롤백하는 것에 수반된 애플리케이션 서버(200)에서 실행되는 자바 시스템의 컴포넌트의 일례를 도시하는 블록도이다. 에이전트 클래스 파일을 포함하는 jar 파일(340)은 agent.jar(340)이라고 언급된다. agent.jar의 클래스 경로는 "C:＼agent.jar"이다. agent.jar(340)는 도 2에서 에이전트 코드(204)의 일례이고, 변환기(206)를 위한 코드, 에이전트심(208)을 위한 코드, 및 에이전트 클래스(210)를 위한 코드를 포함한다. 자바 부트스트랩 클래스로더(342)는 agent.jar의 하나 이상의 클래스를 JVM(250)에 로딩하기 위하여 agent.jar(340)로부터의 코드에 액세스할 수 있다. 일반적으로, 본 명세서에 설명된 구성을 사용할 때, 부트스트랩 클래스로더(342)는 코드를 로딩하고 이 로딩된 코드를 클래스 파일 변환기(344)에 제공한다. 일 실시예에서, 클래스 파일 변환기(344)는 부트스트랩 클래스로더(342)로부터 여기에 제공되는 코드를 인스트루먼트한 다음 인스트루먼트된 코드를 다시 자바 가상 머신(250)에 제공하기 위해 부트스트랩 클래스로더(342)로 리턴(return)하는 옵션을 구비할 수 있다. 일부 실시예에서, 추가적인 클래스로더가 부트스트랩 클래스로더(342) 대신에 또는 이에 추가하여 사용될 수 있다.

도 4는 에이전트를 언제 업데이트할지 및 언제 롤백할지를 클래스 파일 변환기(344)에 지시하는 업데이트 관리자(260)를 도시한다. 에이전트를 업데이트할 때, 업데이트된 클래스 파일은 agent.jar의 다른 버전으로 저장된다. 그러나, 이 agent.jar는 원래의 agent.jar와는 상이한 위치에 저장되어야 한다. 그리하여, 일 실시예에서, 하나 이상의 업데이트 디렉토리가 생성된다. 예를 들어, 업데이트된 agent.jar(350)는 C:＼updateX＼에 저장될 수 있다. 일 실시예에서, 업데이트된 agent.jar는 새로운 변환기(352), 새로운 에이전트심(354), 폴백에이전트심(FallbackAgentShim)(356) 및 새로운 에이전트 클래스(358)를 포함할 수 있다. 일부 실시예에서, 변환기(352), 에이전트심(354), 에이전트폴백심(356) 및 에이전트 클래스(358)의 서브세트는 새로운 것이고 나머지 부분은 예전의 것이다. 업데이트 관리자(260)가 클래스 파일 변환기(344)에 에이전트를 업데이트할 것을 지시하면, 클래스 파일 변환기(344)는 JVM이 에이전트에 대한 클래스 파일을 재로딩할 것을 요청한다. 에이전트에 대한 클래스 파일을 재로딩하는 요청에 응답하여, 부트스트랩 클래스로더(342)는 agent.jar(340)로부터 클래스 파일에 액세스하고, 이 클래스 파일을 클래스 파일 변환기(344)에 제공한다. 클래스 파일 변환기(344)는 agent.jar로부터의 클래스 파일을 업데이트된 agent.jar(350)로부터의 코드(클래스 파일)로 대체하고, 업데이트된 클래스 파일(346)을 부트스트랩 클래스로더(342)로 리턴하며, 이 클래스로더는 업데이트된 코드를 자바 가상 머신에 제공한다. 부트스트랩 클래스로더(342)가 업데이트된 클래스 파일을 수신하면, 이 클래스로더는 대체된 버전이 아니라 원래의 에이전트 클래스 파일의 인스트루먼트된 버전을 수신한 것으로 생각한다. 이런 방식으로, 클래스 경로 C:＼agent.jar로부터의 클래스 파일은 클래스 경로 외부의 파일로부터의 (즉, C:＼updateX＼agent.jar로부터의) 클래스 파일로 대체된다. 일 실시예에서, 다수의 업데이트 디렉토리가 있을 수 있고, 업데이트 관리자(260)는 클래스 파일 변환기(344)에 어느 업데이트 디렉토리로부터 업데이트된 파일을 취해야 할지를 나타낸다. 일부 대안적인 실시예에서, 애플리케이션의 개발자는 부트스트랩 클래스로더(342)를 대체하도록 추가적인 클래스로더(즉, 예를 들어, 추가적인 클래스로더(360))를 구현할 수 있다. 추가적으로, 다른 실시예에서, 시스템은 다수의 클래스 파일 변환기를 포함할 수 있다.

에이전트를 이전의 버전으로 롤백하는 일 실시예를 가능하게 하기 위하여, 업데이트된 agent.jar는 새로운 에이전트심(354)과 새로운 에이전트폴백심(356)을 포함한다. 새로운 에이전트심(354)은 여러 에이전트 클래스(358)를 호출하는 코드를 구비한다. 따라서, 애플리케이션은 이들 호출을 에이전트 클래스(358)의 적절한 메소드로 재지향시키는 에이전트심(354)에 대한 호출을 포함하도록 인스트루먼트된다. 에이전트폴백심(356)은 이전의 에이전트에 대한 에이전트 클래스에 대한 재지향을 포함할 수 있다. 예를 들어, 도 4는 이전의 에이전트 버전에 대한 이전의 에이전트 클래스(362)를 도시한다. 에이전트를 업데이트시키는 부분으로서 클래스 파일 변환기(344)는 추가적인 클래스로더(360) (에이전트 클래스(358)를 로딩한 부트스트랩 클래스로더(342) 또는 임의의 다른 클래스로더와는 상이한 것)에 이전의 에이전트 클래스(362)를 로딩할 것을 지시한다. 이전의 에이전트 클래스(362)는 에이전트 클래스(358)와 동일한 패키지 네임(package name)을 구비하고 있기 때문에, 이들은 상이한 네임 스페이스 내에 있도록 상이한 클래스로더에 의해 로딩되어야 한다. 에이전트의 핫 롤백을 수행하기 위하여, 시스템은 로딩된 에이전트심(354)을 로딩된 에이전트폴백심(356)으로 대체하여, 애플리케이션이 업데이트된 에이전트 클래스(358)가 아니라 이전의 에이전트 클래스(362)에 액세스할 수 있도록 할 수 있다. 이런 방식으로 업데이트 관리자(260)는 에이전트 클래스(358)로부터 이전의 에이전트 클래스(362)로 롤백할 수 있다.

도 5, 도 6, 도 7a, 도 7b 및 도 8은 도 2 내지 도 4의 실시예에 따른 자바 인스트루먼테이션 API의 -javaagent 옵션을 사용하여 구현된 에이전트의 버전을 관리하는 추가적인 상세를 기술하는 흐름도이다. 이 점에서, 도 5의 흐름도는 도 1의 블록(102 내지 110)의 일 실시예의 추가적인 상세를 제공한다. 도 7a 내지 도 7b는 도 1의 블록(112)의 일 실시예의 추가적인 상세를 제공하는 흐름도를 기술한다. 도 8은 도 1의 블록(118)의 일 실시예의 추가적인 상세를 제공한다.

도 5에서 블록(402)은 클래스 경로를 agent.jar로 지정하는 -avaagent 파라미터로 JVM을 론칭하는 단계를 포함한다. 블록(404)에서, 부트스트랩 클래스로더(342) (도 4 참조)는 agent.jar에 액세스하고 agent.jar를 록킹한다. agent.jar를 록킹한다는 것은, 다른 어느 프로세스라도 agent.jar의 컨텐츠를 변경하지 못한다는 것을 의미한다. 일부 실시예에서, agent.jar를 록킹하면 어떤 다른 프로세스 또는 개체(entity)라도 agent.jar에 액세스하는 것이 금지된다. 블록(406)에서, 부트스트랩 클래스로더(342)는 "프리메인" 메소드를 포함하는 agent.jar로부터 클래스를 판독한다. 블록(408)에서, 부트스트랩 클래스로더(342)는 "프리메인" 메소드를 실행한다. 블록(410)에서, "프리메인" 메소드는 클래스 파일 변환기(344)를 부트스트랩 클래스로더(342)에 등록(register)한다. 블록(412)에서, 부트스트랩 클래스로더(342)는 클래스 파일 변환기(344)로 구현될 agent.jar(340)로부터 변환기(206)를 로딩한다. 블록(414)에서, JVM은 애플리케이션(252)에 필요한 클래스 파일을 식별한다. 블록(416)에서, JVM은 부트스트랩 클래스로더(342)에 필요한 클래스 파일을 로딩할 것을 지시한다. 블록(418)에서, 부트스트랩 클래스로더(342)는 애플리케이션을 버퍼로 판독한다. 블록(420)에서, 부트스트랩 클래스로더(342)는 (클래스 파일 변환기가 블록(410)에 등록되었기 때문에) 버퍼로 판독된 클래스에 대한 바이트 코드를 클래스 파일 변환기(344)에 제공한다. 블록(422)에서, 클래스 파일 변환기(344)는 클래스 파일에 대한 바이트 코드를 동적으로 인스트루먼트한다. 예를 들어, 클래스 파일 변환기(344)는 에이전트심(208)의 메소드에 호출을 추가한다. 블록(424)에서, 클래스 파일 변환기(344)는 인스트루먼트된 코드를 부트스트랩 클래스로더(342)로 리턴한다. 블록(426)에서, 부트스트랩 클래스로더(342)는 인스트루먼트된 코드를 JVM(250)에 제출한다. JVM은 애플리케이션을 실행하는데 다수의 클래스 파일을 로딩할 필요가 있기 때문에 블록(414 내지 426)이 다수회 반복될 필요가 있을 수 있는 것이 가능한 것으로 인해, 블록(426)으로부터 다시 블록(414)으로 화살표 방향의 실행이 존재한다. 적절한 클래스 파일이 인스트루먼트된 바이트 코드를 일단 구비하면, 애플리케이션은 이제 관리되는 애플리케이션이 된다. 블록(428)에서, 관리되는 애플리케이션은 에이전트로 실행된다.

도 6은 에이전트로 애플리케이션을 실행(도 5의 블록(428))하는 것의 추가적인 상세를 기술하는 흐름도이다. 도 6의 블록(470)에서, JVM은 메소드를 호출한다. 이 호출이 JVM에 아직 로딩되지 않은 클래스에 있는 메소드에 대한 호출이면, 이 클래스는 로딩될 필요가 있다. 로딩될 필요가 있는 클래스가 애플리케이션 (예를 들어, 애플리케이션 코드(202))에 대한 것이라면, 이 클래스는 블록(474)에서 애플리케이션으로부터 로딩될 수 있다. 로딩될 필요가 있는 클래스가 에이전트에 대한 것(예를 들어, 에이전트 코드(204))이라면, 이 클래스는 블록(476)에서 에이전트로부터 로딩될 수 있다. 블록(474)과 블록(476) 후에, 프로세스는 블록(470)에서 다시 계속된다. 따라서, 첫째 에이전트심 내 클래스의 호출이 호출되면, 에이전트심(208)은 (이것이 아직 로딩되지 않았다면) 로딩될 필요가 있다. 호출이 에이전트 클래스(210)로 재지향되면, 추가적인 에이전트 클래스(210)가 로딩될 수 있다. 도 6의 프로세스는 애플리케이션의 실행에 걸쳐 계속될 수 있다. 본 명세서에 설명된 바와 같이 클래스 파일이 로딩될 때, 클래스 파일은 클래스 파일 변환기(344)에 의해 인스트루먼트될 수 있다. 블록(470)에서 메소드의 호출이 JVM에 로딩된 클래스 내에 있는 메소드에 대한 호출이라면, 이 클래스는 로딩될 필요가 없다.

도 7a 내지 도 7b는 클래스 경로(c:＼agent.jar) 내 agent.jar(340)가 록킹된 동안, 관리되는 애플리케이션이 (애플리케이션을 중지하거나 재시작함이 없이) 계속 실행되는 동안, 및 JVM이 (JVM을 중지하거나 재시작함이 없이) 계속 실행되는 동안, 에이전트를 업데이트하는 것의 추가적인 상세를 제공하는 흐름도를 도시한다. 블록(520)에서, 자동화된 프로세스 또는 사람이 업데이트된 에이전트심(354), 업데이트된 에이전트폴백심(356), 및 업데이트된 에이전트 클래스 파일(358)을 포함하는 업데이트된 agent.jar를 생성한다. 블록(522)에서, 새로운 agent.jar 파일이 업데이트 디렉토리(예를 들어, c:＼updateX＼)에 저장된다. 일 실시예에서, 블록(520)과 블록(522)은 사람에 의해 수행된다. 다른 실시예에서, 블록(520)과 블록(522)은 자동화된 프로세스(예를 들어, 소프트웨어)에 의해 수행될 수 있다. 블록(524)에서, 업데이트 관리자(260)는 클래스 파일 변환기(344)에 에이전트를 업데이트할 것을 지시하고 이 업데이트를 식별한다. 예를 들어, 업데이트 관리자(260)는 업데이트 디렉토리를 클래스 파일 변환기(344)에 통지하거나 또한 다른 수단을 사용하여 다수의 가능한 업데이트 중 어느 것을 사용할지를 식별한다. 일 실시예에서, 사람 오퍼레이터는 업데이트 관리자(260)에 클래스 파일 변환기(344)에 컨택(contact)할 것을 지시한다. 다른 실시예에서, 자동화된 프로세스는 업데이트 관리자(260)에 클래스 파일 변환기(344)와 컨택할 것을 지시하거나 또는 업데이트 관리자(260)는 업데이트 디렉토리를 모니터링하고, 새로운 agent.jar이 업데이트 디렉토리에 저장될 때 클래스 파일 변환기(344)와 자동으로 컨택한다.

블록(526)에서, 클래스 파일 변환기(344)는 업데이트된 agent.jar에 액세스한다. 클래스 파일 변환기(344)가 업데이트된 agent.jar에서 새로운 클래스 파일 변환기(예를 들어, 클래스 파일 변환기(352))를 발견한다면, 블록(530) 내지 블록(536)이 클래스 파일 변환기를 업데이트하도록 수행될 수 있다. 그렇지 않다면, 프로세스는 블록(560)으로 스킵(skip)할 수 있다(도 7b 참조).

클래스 파일 변환기를 업데이트하는 것은 새로운 클래스 파일 변환기에 대한 업데이트된 코드의 판독을 포함하는 블록(530)에서 시작한다. 블록(532)에서, 새로운 클래스 파일 변환기가 JVM에 등록된다(도 5의 블록(410) 참조). 블록(534)에서, 기존의 클래스 파일 변환기(이는 또한 구(old) 클래스 파일 변환기로 알려진 것임)는 JVM에 등록되어 있지 않다. 블록(536)에서, 새로운 클래스 파일 변환기(업데이트된 변환기)가 실행되거나 동작된다. 블록(536) 후에, 프로세스는 도 7b의 블록(560)에서 계속된다.

블록(560)(도 7b 참조)에서, 클래스 파일 변환기(344)는 에이전트 클래스 파일을 로딩하는 요청을 JVM에 송신한다. 에이전트 클래스 파일이 이미 로딩되어 있을 가능성이 있으므로, 그래서 이것은 에이전트의 클래스 파일에 대한 바이트 코드의 동적 인스트루먼트를 수행하기 위하여 클래스 파일을 재로딩하기 위한 명시적인 요청이다. 블록(562)에서, JVM은 부트스트랩 클래스로더(342)에 에이전트 클래스 파일 중 하나를 로딩할 것을 지시한다. 블록(564)에서, 부트스트랩 클래스로더(342)는 (원래의 agent.jar 파일(340))로부터 에이전트 클래스 파일 중 하나를 버퍼로 판독한다. 블록(566)에서, 부트스트랩 클래스로더(342)는 이 에이전트 클래스 파일을 현재 클래스 파일 변환기(344)에 제공한다. 블록(568)에서, 현재 클래스 파일 변환기(344)는 (에이전트를 위한 클래스 경로 내에 없는) 업데이트된 agent.jar로부터, 예를 들어 에이전트 클래스(358)로부터 대응하는 클래스 파일에 액세스한다. 블록(570)에서, 클래스 파일 변환기(344)는 구 에이전트(즉, agent.jar(340)로부터)에 대한 바이트 코드를 업데이트된 에이전트(즉, update＼agent.jar(350)로부터)로부터 대체 바이트 코드로 대체하여, 동적 바이트 코드 인스트루먼트를 수행한다. 블록(572)에서, 클래스 파일 변환기(344)는 새로운/인스트루먼트된 바이트 코드를 부트스트랩 클래스로더(342)에 출력한다. 블록(574)에서, 부트스트랩 클래스로더(342)는 바이트 코드를 JVM(250)으로 전달한다. 로딩될 필요가 있는 클래스 파일이 에이전트 내에 더 있다면, 프로세스는 블록(562)으로 백루프를 수행하고; 그렇지 않으면, 프로세스는 블록(578)에서 계속된다.

블록(578)에서, 부트스트랩 클래스로더(342)는 업데이트된 agent.jar로부터 에이전트심(354) 및 에이전트폴백심(356)을 로딩한다. 블록(580)에서, 클래스 파일 변환기(344)는 (일부 실시예에서) 에이전트의 이전의 버전에 대한 에이전트 클래스 파일의 전부(또는 그 서브세트)를 포함하는 이전의 에이전트 클래스(362)를 로딩할 것을 추가적인 클래스로더(360)에 지시한다. 구체적으로, 블록(580)은 에이전트폴백심(356)에 의해 호출되는 메소드를 구비하는 클래스 파일을 로딩할 것을 추가적인 클래스로더(360)에 지시하는 클래스 파일 변환기(344)를 포함할 수 있다. 이전의 버전에 대한 클래스 파일은 하나의 이전의 버전으로부터 오는 일부 클래스 파일이고 일부 클래스 파일은 다른 이전의 버전으로부터 오는 것일 수 있는 것이 (일부 실시예에서) 가능하다. 다른 실시예에서, 클래스 파일 전부가 동일한 이전의 버전으로부터 올 수 있다. 블록(580)은 추가적인 클래스로더(360)(부트스트랩 클래스로더(342)와는 다른 것, 또는 다른 클래스로더가 에이전트 클래스(358)에 사용된다)를 사용하되, 이전의 에이전트 클래스(362)가 에이전트 클래스(358)와는 상이한 네임 스페이스에 있도록 사용한다. 블록(580)은 이전의 에이전트 클래스(362)에 대해 블록(562 내지 576)의 기능을 수행하는 단계를 포함한다는 것이 주목된다. 에이전트의 이전의 버전에 대한 클래스 파일은 후술되는 바와 같이 에이전트의 핫 롤백이 가능하도록 추가적인 클래스로더(360)에 의해 로딩되었다.

새로운 에이전트에 업데이트를 완료하기 위하여, 애플리케이션에 대한 바이트 코드는 구 에이전트에 대한 에이전트심(208)이 아니라 새로운 에이전트에 대한 에이전트심(354)을 참조(reference)하도록 변경(예를 들어, 인스트루먼트)될 수 있다. 다시 말해, 관리되는 애플리케이션(352)(도 3 참조)의 프로브(354)는 (이 실시예에서) 구 에이전트가 아니라 새로운 에이전트를 나타내야 한다. 이 점에서, 블록(582)은 관리되는 애플리케이션에 대해 이전에 인스트루먼트된 모든 클래스 파일을 재로딩하는 요청을 JVM에 송신하는 클래스 파일 변환기(344)를 포함한다. 블록(584)에서, JVM은 로딩될 필요가 있는 클래스 파일을 식별한다. 블록(586)에서, JVM은 이 식별된 클래스 파일을 로딩할 것을 부트스트랩 클래스로더(342)(또는 상이한 클래스로더)에 지시한다. 블록(588)에서, 부트스트랩 클래스로더(342)는 이 식별된 클래스를 버퍼로 판독한다. 블록(590)에서, 부트스트랩 클래스로더(342)는 이 클래스에 대한 바이트 코드를 적절한 클래스 파일 변환기(344)에 송신한다. 블록(592)에서, 클래스 파일 변환기(344)는 클래스 파일의 바이트 코드를 동적으로 인스트루먼트하여, 구 에이전트심(208)을 나타내는 것으로부터 업데이트된 에이전트를 위한 새로운 에이전트심(354)을 나타내는 것으로 호출을 변경한다. 블록(594)에서, 클래스 파일 변환기(344)는 인스트루먼트된 바이트 코드를 부트스트랩 클래스로더(342)에 리턴한다. 블록(596)에서, 부트스트랩 클래스로더(342)는 인스트루먼트된 바이트 코드를 JVM(250)에 제출한다. 만약 클래스 파일이 더 있다면(블록(598)), 프로세스는 블록(584)으로 백루프를 수행한다. 애플리케이션의 모든 클래스 파일이 인스트루먼트되었다면, 업데이트는 완료되고(블록(600)), 애플리케이션은 블록(600)에서 업데이트된 에이전트로 실행된다.

전술된 프로세스는, 기존의 에이전트의 바이트 코드(에이전트를 위한 클래스 경로에 있는 것) 대신에 업데이트된 에이전트의 바이트 코드(에이전트를 위한 클래스 경로에 없는 것)를 사용하는 동적 바이트 코드 인스트루먼트를 사용하여, 에이전트로 하여금, agent.jar가 록킹되는 동안, 애플리케이션이 (애플리케이션을 중지하거나 재시작함이 없이) 실행되는 동안, 및 JVM이 (JVM을 중지하거나 재시작함이 없이) 실행되는 동안, 업데이트될 수 있게 한다.

바람직하지는 않지만, 업데이트가 문제 또는 원치않는 문제를 야기할 수 있는 때가 있다. 이 상황에서, 에이전트를 이미 알려진 허용가능한 버전으로 롤백하는 것이 필요할 수 있다. 도 8은 에이전트에 대한 이전의 코드 버전을 사용하기 위해 에이전트를 롤백하는 일 프로세스를 기술하는 흐름도이다. 이전의 버전은 현재 버전과 상이한 많은 코드를 구비하거나 또는 현재 버전과 단지 작은 양만큼만 상이한 코드를 구비할 수 있다. 이 롤백은, JVM과 관리되는 애플리케이션이 (이들을 중지시키거나 재시작함이 없이) 계속 실행되는 동안 에이전트가 이전의 버전으로 롤백되기 때문에 핫 롤백(hot rollback)이라고 언급된다. 도 8의 블록(70)에서, 에러, 버그 또는 성능 문제가 발생할 수 있다. 롤백은 에러, 버그, 또는 성능 문제가 없는 경우에도 수행될 수 있다는 것이 주목된다. 블록(752)에서, 업데이트 관리자(또는 다른 개체)는 롤백이 필요한지를 (자동으로 또는 수동으로) 결정한다. 일부 실시예에서, 사람 오퍼레이터는 롤백이 필요한지 여부를 결정하고 롤백이 수행될 것을 업데이트 관리자(260)에 지시한다. 다른 실시예에서, 모니터링 프로세스는 이 결정을 자동으로 수행하고 업데이트 관리자(260)에 변경을 수행할 것을 지시한다. 일부 실시예에서, 업데이트 관리자(260)는 롤백이 수행될지 여부를 자동으로 결정하는 로직을 포함할 수 있다. 블록(754)에서, 업데이트 관리자(260)는 이전의 에이전트 버전으로 에이전트를 롤백(예를 들어, 에이전트에 대한 이전의 코드 버전을 사용)할 것을 클래스 파일 변환기(344)에 지시한다.

블록(756)에서, 업데이트 관리자(260)로부터의 인스트럭션에 응답하여, 클래스 파일 변환기(344)는 애플리케이션에 대해 이전에 인스트루먼트된 모든 클래스 파일을 재로딩하는 요청을 JVM에 송신한다. 블록(758)에서, JVM은 로딩될 필요가 있는 클래스 파일을 식별한다. 블록(760)에서, JVM은 부트스트랩 클래스로더(342)에 이 식별된 클래스 파일을 로딩할 것을 지시한다. 블록(762)에서, 부트스트랩 클래스로더(342)는 이 식별된 클래스 파일을 버퍼로 판독한다. 블록(764)에서, 부트스트랩 클래스로더(342)는 클래스 파일에 대한 바이트 코드를 클래스 파일 변환기(344)에 송신한다. 블록(766)에서, 클래스 파일 변환기(344)는 여기에 제공되었던 클래스 파일에 대한 바이트 코드를 동적으로 인스트루먼트한다. 이 동적으로 인스트루먼트하는 것은 에이전트심(354)의 메소드의 모든 호출을 에이전트폴백심(356)의 메소드의 호출로 변경하는 단계를 포함한다. 블록(768)에서, 클래스 파일 변환기(344)는 인스트루먼트된 바이트 코드를 부트스트랩 클래스로더(342)에 리턴한다. 블록(770)에서, 부트스트랩 클래스로더(342)는 인스트루먼트된 바이트 코드를 JVM(250)에 제출한다. 만약 인스트루먼트될 필요가 있는 클래스 파일이 관리되는 애플리케이션 내에 더 있다면(블록(772)), 프로세스는 블록(758)으로 백루프를 수행하고; 그렇지 않다면, JVM은 관리되는 애플리케이션을 계속 실행하되, 새로이 로딩된 이전의 에이전트 버전으로 애플리케이션을 실행한다(블록(774)).

도 8은 관리되는 애플리케이션 내 프로브(254)가 에이전트심으로부터 에이전트폴백심으로 재지향되는 프로세스를 기술한다. 프로브(254)가 지향하는 곳을 변경시키는 것에 의해, 관리되는 애플리케이션은 이제 에이전트폴백심에 의해 호출되는 이전의 에이전트 클래스(362)에 액세스할 수 있다; 그리하여 관리되는 애플리케이션은 이제 이전의 에이전트 버전으로 실행될 수 있다. 이 프로세스는 JVM 및 관리되는 애플리케이션이 (이들을 중지하거나 재시작함이 없이) 실행되고 있는 동안 에이전트 코드의 핫 롤백을 가능하게 한다.

도 9 및 도 10은 자바 실행시간 환경이 다수의 이전의 에이전트 버전 중에서 하나의 버전을 선택할 수 있는, 에이전트를 롤백하는 다른 실시예를 기술한다. 도 9에 도시된 프로세스는 다수의 에이전트폴백심을 로딩하기 위하여 도 7b의 블록(578)과 블록(580)을 대체(또는 증강(augment))한다. 예를 들어, 블록(820)에서 부트스트랩 클래스로더(342)는 에이전트폴백심1을 로딩하고, 블록(822)에서 부트스트랩 클래스로더(342)는 에이전트폴백심2을 로딩하고, ... , 블록(824)에서 부트스트랩 클래스로더는 에이전트폴백심N을 로딩한다. 따라서, N개의 에이전트폴백심이 로딩될 수 있다. 일 실시예에서, 부트스트랩 클래스로더(342)는 모든 폴백심을 (동시에, 직렬로 또는 다른 방식으로) 로딩한다. 다른 실시예에서, 상이한 클래스로더는 상이한 에이전트폴백심을 로딩할 수 있다. 일 실시예에서, 모든 에이전트폴백심은 단일 agent.jar에 있는 반면, 다른 실시예에서, 상이한 에이전트폴백심은 상이한 agent.jar에 있을 수 있다.

도 9의 블록(826)에서 제1 추가적인 클래스로더는 에이전트폴백심1에 의해 참조된 이전의 에이전트 버전에 대한 에이전트 클래스 파일을 로딩하고, 블록(828)에서 제2 추가적인 클래스로더는 에이전트폴백심2에 의해 참조된 이전의 에이전트 버전에 대한 에이전트 클래스 파일을 로딩하고, ..., 블록(830)에서 제N번째 추가적인 클래스로더는 에이전트폴백심N에 의해 참조된 이전의 에이전트 버전에 대한 에이전트 파일을 로딩한다. 따라서, 로딩된 각 에이전트폴백심에 대해, 각 에이전트폴백심에 의해 지시된 클래스 파일의 세트가 또한 로딩될 수 있다. 클래스 파일의 각 세트는 동일한 패키지 네임을 구비할 수 있으므로, 일 실시예에서 이들은 상이한 네임 스페이스에 있을 수 있는 상이한 클래스로더에 의해 로딩된다. 다른 실시예에서, 클래스 파일의 네임은 동일한 네임 스페이스에 로딩될 수 있도록 변경될 수 있다.

도 10은 도 9의 실시예와 함께 핫 롤백을 수행하는 프로세스를 기술한다. 도 10의 블록 중 많은 블록이 도 8의 블록과 유사하다. 블록(910)에서, 에러, 버그 또는 성능 문제가 발생할 수 있다. 블록(912)에서, 업데이트 관리자(260)(또는 다른 개체)는 롤백이 필요한지를 (자동으로 또는 수동으로) 결정한다. 블록(914)에서, 업데이트 관리자(260)(또는 다른 개체)는 이전의 버전 중 어느 버전으로 롤백할지를 결정한다. 예를 들어, 도 9는 N개의 에이전트 버전이 롤백될 수 있는 것을 나타낸다. 블록(914)에서, 업데이트 관리자는 N개의 버전 중 어느 것으로 롤백할 지를 결정한다. 일 실시예에서, 업데이트 관리자는 어느 버전으로 롤백할 지를 (에러 없이 동작한 마지막 버전을 결정하는 것에 의해) 자동으로 결정하거나 또는 사람이 수동으로 어느 버전으로 롤백할지를 업데이트 관리자에 알려줄 수 있다. 에러, 버그 또는 성능 문제가 발생하지 않는 경우에도 에이전트가 롤백될 수 있다는 것이 주목된다.

블록(916)에서, 업데이트 관리자(260)는 클래스 파일 변환기(344)에 선택된 버전(흐름도에서 버전 X로 언급된 것)으로 롤백할 것을 지시한다. 블록(918)에서, 클래스 파일 변환기(344)는 애플리케이션에 대해 이전에 인스트루먼트된 클래스를 재로딩하는 요청을 JVM에 송신한다. 블록(920)에서, JVM은 애플리케이션으로부터 요구된 클래스 파일을 식별한다. 블록(922)에서, JVM은 부트스트랩 클래스로더(342)에 이 클래스를 로딩할 것을 지시한다. 블록(924)에서, 부트스트랩 클래스로더(342)는 이 식별된 클래스를 버퍼로 판독한다. 블록(926)에서, 부트스트랩 클래스로더(342)는 이 클래스에 대한 바이트 코드를 클래스 파일 변환기(344)에 송신한다. 블록(928)에서, 클래스 파일 변환기(344) (또는 다른 클래스 파일 변환기)는 에이전트심의 메소드를 호출한 호출을 에이전트폴백심(X)의 메소드를 호출한 것으로 변경하는 것에 의해 여기에 제공된 클래스 파일에 대한 바이트 코드를 동적으로 인스트루먼트한다. 블록(930)에서, 클래스 파일 변환기(930)는 이 인스트루먼트된 바이트 코드를 부트스트랩 클래스로더(342)로 리턴한다. 만약 인스트루먼트할 클래스 파일이 더 있다면(블록(934)), 프로세스는 블록(920)으로 백루프를 수행하고; 그렇지 않은 경우, 시스템은 관리되는 애플리케이션을 계속 실행하되, 이전의 에이전트로 계속 실행한다(블록(936)).

볼 수 있는 바와 같이, 도 10의 프로세스는 관리되는 애플리케이션과 JVM이 (이들을 중지시키거나 재시작함이 없이) 실행되고 있는 동안 및 agent.jar 파일이 에이전트 클래스 경로에 없는 jar 파일로부터 에이전트에 대한 클래스 파일에 바이트 코드를 주입하는 것에 의해 록킹된 동안, 많은 가능한 이전의 에이전트 중 하나의 이전의 에이전트에 커스터마이즈된(customized) 핫 롤백을 제공한다.

도 11은 전술된 기술을 구현하는데 사용될 수 있는 컴퓨터 시스템의 하이 레벨 블록도를 도시한다. 도 11의 컴퓨터 시스템은 메인 메모리(972)와 통신하는 프로세서 유닛(970)을 포함한다. 프로세서 유닛(970)은 단일 마이크로프로세서를 포함하거나, 또는 멀티 프로세서 시스템으로서 컴퓨터 시스템을 구성하는 복수의 마이크로프로세서를 포함할 수 있다. 이들 하나 이상의 프로세서는 전술된 메소드를 수행할 수 있다. 메인 메모리(972)는 부분적으로 프로세서 유닛(970)에 의해 실행되는 인스트럭션과 데이터를 저장한다. 본 명세서에 설명된 시스템이 완전히 또는 부분적으로 소프트웨어로 구현되는 경우, 메인 메모리(972)는 동작시에 실행가능한 코드를 저장할 수 있다. 메인 메모리(972)는 고속 캐시 메모리 뿐만 아니라 동적 랜덤 액세스 메모리(DRAM)의 뱅크(banks)를 포함할 수 있다. 예를 들어, 메인 메모리(972)는 Agent.jar 파일, 업데이트된 및 이전의 Agent.jar 파일, 애플리케이션 코드(202), 에이전트 코드(204), JVM(252)을 실행하는 코드 및/또는 애플리케이션 서버(200)를 실행하는 코드를 저장할 수 있다.

일 실시예에서, 메인 메모리(972)(또는 저장 디바이스)는 (일부 실시예에서) 에이전트를 적어도 부분적으로 한정하는 Agent.jar 파일일 수 있는 제1 코드 저장 유닛을 포함하는 코드를 저장한다. 하나 이상의 프로세서(970)는 JVM, 자바 애플리케이션 및 이 자바 애플리케이션을 위한 에이전트를 실행하여 에이전트가 자바 인스트루먼테이션 API의 -javaagent 옵션을 사용하여 구현되도록 구성될 수 있다. 제1 코드 저장 유닛은 에이전트의 클래스에 대한 코드를 저장한다. 애플리케이션이 실행되고 있는 동안 하나 이상의 프로세서는 제1 코드 저장 유닛을 록킹한다. 제1 코드 저장 유닛이 록킹된 동안 및 애플리케이션과 JVM이 실행되고 있는 동안, 에이전트는 구 에이전트 코드 대신에 새로운 코드를 사용하는 것에 의해 업데이트된다. 하나 이상의 프로세서는 애플리케이션 및/또는 자바 가상 머신을 실행하는 동안 에이전트에 대한 이전의 코드 버전을 사용하기 위해 에이전트의 핫 롤백을 더 수행할 수 있다.

도 11의 시스템은 대용량 저장 디바이스(974), 주변 디바이스(들)(976), 유저 입력 디바이스(들)(980), 출력 디바이스(978), 휴대용 저장 매체 드라이브(들)(982), 그래픽 서브시스템(984) 및 출력 디스플레이(986)를 더 포함한다. 간략화를 위하여, 도 11에 도시된 컴포넌트들은 단일 버스(988)를 통해 연결된 것으로 도시된다. 그러나, 이 컴포넌트들은 하나 이상의 데이터 전송 수단을 통해 연결될 수 있다. 예를 들어, 프로세서 유닛(970) 및 메인 메모리(972)는 국부 마이크로프로세서 버스를 통해 연결될 수 있고, 대용량 저장 디바이스(974), 주변 디바이스(들)(976), 휴대용 저장 매체 드라이브(들)(982), 및 그래픽 서브시스템(984)은 하나 이상의 입력/출력(I/O) 버스를 통해 연결될 수 있다. 자기 디스크 드라이브 또는 광학 디스크 드라이브로 구현될 수 있는 대용량 저장 디바이스(974)는 프로세서 유닛(970)에 의해 사용되는 데이터 및 인스트럭션을 저장하는 비휘발성 저장 디바이스이다. 일 실시예에서, 대용량 저장 디바이스(970)는 메인 메모리(572)에 로딩하기 위하여 본 명세서에 설명된 기술을 구현하기 위한 시스템 소프트웨어를 저장한다. 대용량 저장 디바이스(970)는 현재, 업데이트된, 및 이전의 Agent.jar 파일을 저장하는데 더 사용될 수 있다. 주변 디바이스(들)(976)는 입력/출력(I/O) 인터페이스와 같은 임의의 유형의 컴퓨터 지원 디바이스를 포함하여, 추가적인 기능을 컴퓨터 시스템에 추가할 수 있다. 예를 들어, 주변 디바이스(들)(976)는 컴퓨터 시스템을 네트워크, 모뎀, 라우터 등에 연결하는 네트워크 인터페이스를 포함할 수 있다. 유저 입력 디바이스(들)(980)는 유저 인터페이스의 일부(예를 들어, 업데이트 관리자(260)를 위한 것)를 제공한다. 유저 입력 디바이스(들)(980)는 영숫자 및 다른 정보를 입력하기 위한 영숫자 키패드; 또는 마우스, 트랙볼, 스타일러스, 또는 커서 방향 키와 같은 포인팅 디바이스를 포함할 수 있다. 텍스트 및 그래픽 정보를 디스플레이하기 위하여, 도 11의 컴퓨터 시스템은 그래픽 서브시스템(984) 및 출력 디스플레이(986)를 포함한다. 출력 디스플레이(986)는 음극선관(CRT) 디스플레이, 액정 디스플레이(LCD) 또는 다른 적절한 디스플레이 디바이스를 포함할 수 있다. 그래픽 서브시스템(984)은 텍스트 및 그래픽 정보를 수신하고, 디스플레이(986)에 출력하기 위해 정보를 처리한다. 추가적으로, 도 11의 시스템은 출력 디바이스(978)를 포함한다. 적절한 출력 디바이스의 예로는 스피커, 프린터, 네트워크 인터페이스, 모니터 등을 포함한다.

도 11의 컴퓨터 시스템에 포함된 컴포넌트들은 본 명세서에 설명된 기술과 사용하기에 적합한 컴퓨터 시스템에서 일반적으로 발견되는 것들이며, 이 기술 분야에 잘 알려진 넓은 범주의 컴퓨터 컴포넌트를 나타내는 것으로 의도된다. 따라서, 도 11의 컴퓨터 시스템은 퍼스널 컴퓨터, 모바일 컴퓨팅 디바이스, 스마트폰, 태블릿, 워크스테이션, 서버, 미니컴퓨터, 메인프레임 컴퓨터, 또는 임의의 다른 컴퓨팅 디바이스일 수 있다. 컴퓨터는 상이한 버스 구성, 네트워크 연결된 플랫폼, 멀티 프로세서 플랫폼, 등을 더 포함할 수 있다. 여러 운영 시스템이 사용될 수 있다.

도면에 있는 흐름도 및 블록도는 본 발명의 여러 양상에 따른 시스템, 방법 및 컴퓨터 프로그램 제품의 가능한 구현의 아키텍처, 기능, 및 동작을 예시한다. 이런 점에서, 흐름도 또는 블록도에 있는 각 블록은 특정 논리 기능(들)을 구현하는 하나 이상의 실행가능한 인스트럭션을 포함하는 모듈, 세그먼트, 또는 코드의 일부를 나타낼 수 있다. 또한 일부 대안적인 구현에서, 블록에 언급된 기능은 도면에 언급된 순서에서 벗어나 일어날 수 있는 것으로 이해된다. 예를 들어, 연속적으로 도시된 2개의 블록은 사실상 실질적으로 동시에 실행되거나 또는 이들 블록은 수반되는 기능에 따라 종종 역순으로 실행될 수도 있다. 또한 블록도 및/또는 흐름도의 각 블록과, 블록도 및/또는 흐름도의 블록의 조합은 특정한 기능이나 동작을 수행하는 특수 목적 하드웨어 기반 시스템에 의하여 또는 특수 목적 하드웨어와 컴퓨터 인스트럭션의 조합에 의하여 구현될 수 있는 것으로 이해된다.

본 명세서에 사용된 용어는 단지 특정 양상을 설명하기 위한 것이고, 본 발명을 제한하려고 의도된 것이 아니다. 본 명세서에 사용된 바와 같이, 단수 형태 "일", "하나의" 및 "상기"는 문맥상 명백히 달리 지시하지 않는 한 복수의 형태를 또한 포함하는 것으로 의도된다. 나아가, "포함하는" 및/또는 "구비하는"이라는 용어는 본 명세서에 사용될 때 언급된 특징, 완전체, 단계, 동작, 요소 및/또는 컴포넌트의 존재를 명시하는 것일 뿐, 하나 이상의 다른 특징, 완전체, 단계, 동작, 요소, 컴포넌트, 및/또는 이들의 그룹의 존재나 추가를 배제하는 것이 아닌 것으로 이해된다.

아래 청구범위에서 임의의 수단 또는 단계 플러스 기능(means or step plus function)에 대응하는 구조, 물질, 동작 및 등가물은 구체적으로 청구된 바와 같이 다른 청구된 요소와 조합하여 그 기능을 수행하기 위한 임의의 개시된 구조, 물질 또는 동작을 포함하는 것으로 의도된다. 본 발명의 상세한 설명은 예시와 설명을 위하여 제시된 것일 뿐, 개시된 형태로 본 발명을 제한하거나 전부 다 나열한 것으로 의도된 것이 아니다. 본 발명의 범위와 사상을 벗어남이 없이 이 기술 분야에 통상의 지식을 가진 자에게는 많은 변형과 변경이 가능할 것이다. 본 발명의 양상은 본 발명의 원리와 실제 응용을 최상으로 설명하여 이 기술 분야에 통상의 지식을 가진 자로 하여금 구상되는 특정 사용에 적합한 여러 변형이 본 발명에 가능하다는 것을 이해할 수 있게 하기 위하여 선택되고 기술된 것이다.

Claims

애플리케이션(Application)을 위한 에이전트(Agent)의 버전(version)들을 관리하는 방법으로서, 상기 방법은,
상기 에이전트에 대한 제 1 심(shim), 상기 에이전트에 대한 제 2 심, 상기 제 1 심에 의해 참조(reference)된 클래스(class)들, 및 상기 제 2 심에 의해 참조된 클래스들을 로딩(loading)하는 단계와;
상기 제 1 심에 대한 호출(call)들을 행하기 위해 상기 애플리케이션을 동적으로 인스트루먼트(instrumenting)하는 단계와;
자바 가상 머신(Java Virtual Machine)에서 상기 애플리케이션으로 상기 에이전트를 실행하는 단계와,
상기 애플리케이션으로 상기 에이전트를 실행하는 단계는 상기 제 1 심 및 상기 제 1 심에 의해 참조된 클래스들에 대한 상기 인스트루먼트된 애플리케이션으로부터의 호출들에 근거하여 상기 에이전트를 실행하는 것을 포함하고;
상기 애플리케이션 및 상기 자바 가상 머신이 계속 실행되는 동안 아울러 상기 에이전트를 구현하도록 되어 있는 코드(code)가 록킹(locking)된 동안 상기 에이전트에 대한 코드의 이전 버전(previous version)을 사용하기 위해 상기 에이전트를 롤백(rolling back)하는 단계와,
상기 롤백된 에이전트를 실행하는 것은 상기 제 2 심에 대한 호출들을 행하기 위해 상기 애플리케이션을 동적으로 인스트루먼트하는 것을 포함하고,
상기 애플리케이션으로 상기 롤백된 에이전트를 실행하는 것은 상기 제 2 심 및 상기 제 2 심에 의해 참조된 클래스들에 대한 상기 인스트루먼트된 애플리케이션으로부터의 호출들에 근거하여 상기 에이전트의 이전 버전을 실행하는 것을 포함하고; 그리고
상기 애플리케이션 및 상기 자바 가상 머신이 계속 실행되는 동안 상기 자바 가상 머신에서 상기 애플리케이션으로 상기 롤백된 에이전트를 실행하는 단계를 포함하는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제1항에 있어서,
상기 제 1 심에 의해 참조된 클래스들은 상기 에이전트에 대한 클래스 경로(class path)에 없는 제 1 jar 파일에 저장되고,
상기 제 2 심에 의해 참조된 클래스들은 상기 에이전트에 대한 클래스 경로에 없는 제 2 jar 파일에 저장되는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제2항에 있어서,
상기 제 1 심에 의해 참조된 클래스들은 제 1 클래스 로더(Class Loader)에 의해 로딩되고 그리고 제 1 네임스페이스(namespace) 내에 있고,
상기 제 2 심에 의해 참조된 클래스들은 제 2 클래스 로더에 의해 로딩되고 그리고 상기 제 1 네임스페이스와는 다른 제 2 네임스페이스 내에 있는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제3항에 있어서,
상기 제 1 심에 의해 참조된 클래스들의 로딩은,
상기 제 1 클래스 로더가 상기 에이전트에 대한 제 1 코드에 액세스(accessing)하는 것과,
상기 제 1 클래스 로더가 상기 에이전트에 대한 상기 제 1 코드를 클래스 파일 변환기(Class File Transformer)에 제공하는 것과,
상기 클래스 파일 변환기가 상기 에이전트에 대한 클래스 경로에 없는 소스(source)로부터 상기 에이전트에 대한 상기 제 1 코드로 바이트 코드(byte code)를 주입하는 것과, 그리고
상기 제 1 클래스 로더가 상기 주입된 바이트 코드를 갖는 상기 제 1 코드를 상기 자바 가상 머신에 제공하는 것을 포함하는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제1항에 있어서,
상기 에이전트는 자바 인스트루먼테이션 API(Java instrumentation API)의 자바 에이전트 옵션(java agent option)을 사용하여 구현되는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제5항에 있어서,
상기 에이전트를 실행하는 것은 제 1 jar 파일로부터 상기 에이전트에 대한 제 1 코드를 실행하는 것을 포함하고,
상기 롤백된 에이전트를 실행하는 것은 제 2 jar 파일로부터 상기 에이전트에 대한 제 2 코드를 실행하는 것을 포함하는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제1항에 있어서,
상기 에이전트를 구현하도록 되어 있는 코드는 제 1 코드이고,
상기 에이전트를 실행하는 것은 상기 에이전트에 대한 클래스 경로에 없는 코드의 제 1 소스로부터 상기 에이전트에 대한 상기 제 1 코드를 실행하는 것을 포함하고,
상기 롤백된 에이전트를 실행하는 것은 상기 에이전트에 대한 클래스 경로에 없는 코드의 제 2 소스로부터 상기 에이전트에 대한 제 2 코드를 실행하는 것을 포함하는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제7항에 있어서,
상기 에이전트를 실행하는 것, 상기 에이전트를 롤백하는 것, 그리고 상기 롤백된 에이전트를 실행하는 것은, 상기 에이전트에 대한 클래스 경로에 있는 코드의 상기 제 1 소스가 록킹된 동안 수행되는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
애플리케이션을 위한 에이전트의 버전들을 관리하는 방법으로서, 상기 방법은,
상기 애플리케이션이 실행되는 동안 상기 애플리케이션으로 상기 에이전트를 실행하는 단계와,
상기 에이전트는 상기 에이전트에 대한 코드의 식별된 소스와 관련되고;
상기 에이전트에 대한 코드의 상기 식별된 소스를 록킹하는 단계와;
상기 에이전트에 대한 코드의 상기 식별된 소스가 록킹된 동안 상기 에이전트에 대한 코드를 업데이트(updating)하는 단계와;
상기 에이전트에 대한 제 1 심을 로딩하는 것, 상기 에이전트에 대한 제 2 심을 로딩하는 것, 상기 제 1 심에 의해 참조된 클래스들을 로딩하는 것, 상기 제 2 심에 의해 참조된 클래스들을 로딩하는 것, 그리고 상기 제 1 심에 대한 호출들을 행하기 위해 상기 애플리케이션을 동적으로 인스트루먼트하는 것을 수행함으로써, 상기 애플리케이션으로 상기 업데이트된 에이전트를 실행하는 단계와;
상기 제 2 심에 대한 호출들을 행하기 위해서 상기 애플리케이션을 동적으로 인스트루먼트함으로써 상기 에이전트에 대한 코드의 상기 식별된 소스가 록킹된 동안 상기 에이전트에 대해 코드의 이전 버전을 사용하기 위해 상기 에이전트를 롤백하는 단계와; 그리고
상기 애플리케이션으로 상기 롤백된 에이전트를 실행하는 단계를 포함하고,
상기 롤백된 에이전트를 실행하는 것은 상기 제 2 심 및 상기 제 2 심에 의해 참조된 클래스들에 대한 상기 인스트루먼트된 애플리케이션으로부터의 호출들에 근거하여 상기 롤백된 에이전트를 실행하는 것을 포함하는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제9항에 있어서,
상기 에이전트는 자바 가상 머신에서 상기 애플리케이션으로 실행되고,
코드를 롤백하는 것은 상기 애플리케이션 및 상기 자바 가상 머신을 실행하는 동안 수행되는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제9항에 있어서,
상기 에이전트는 자바 인스트루먼테이션 API의 자바 에이전트 옵션을 사용하여 구현되는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제9항에 있어서,
상기 제 1 심에 의해 참조된 클래스들은 상기 에이전트에 대한 클래스 경로에 없는 제 1 jar 파일에 저장되고,
상기 제 2 심에 의해 참조된 클래스들은 상기 에이전트에 대한 클래스 경로에 없는 제 2 jar 파일에 저장되는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제12항에 있어서,
상기 제 1 심에 의해 참조된 클래스들은 제 1 클래스 로더에 의해 로딩되고 그리고 제 1 네임스페이스 내에 있고,
상기 제 2 심에 의해 참조된 클래스들은 제 2 클래스 로더에 의해 로딩되고 그리고 상기 제 1 네임스페이스와는 다른 제 2 네임스페이스 내에 있는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제13항에 있어서,
상기 제 1 심에 의해 참조된 클래스들의 로딩은,
상기 제 1 클래스 로더가 상기 에이전트에 대한 제 1 코드에 액세스하는 것과,
상기 제 1 클래스 로더가 상기 에이전트에 대한 상기 제 1 코드를 클래스 파일 변환기에 제공하는 것과,
상기 클래스 파일 변환기가 상기 에이전트에 대한 클래스 경로에 없는 소스로부터 상기 에이전트에 대한 상기 제 1 코드로 바이트 코드를 주입하는 것과, 그리고
상기 제 1 클래스 로더가 상기 주입된 바이트 코드를 갖는 상기 제 1 코드를 실행 엔진(execution engine)에 제공하는 것을 포함하는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
컴퓨팅 장치(computing apparatus)로서, 상기 컴퓨팅 장치는,
에이전트를 적어도 부분적으로 정의하는 코드의 제 1 저장 유닛(storage unit)을 포함하는 코드를 저장하는 저장 디바이스(storage device)와; 그리고
상기 저장 디바이스와 통신하는 하나 이상의 프로세서(processor)들을 포함하고,
상기 하나 이상의 프로세서들은 자바 가상 머신을 구현함과 아울러 자바 인스트루먼테이션 API의 자바 에이전트 옵션을 사용하여 애플리케이션을 위한 상기 자바 가상 머신에서 실행되는 상기 에이전트를 구현하고,
상기 하나 이상의 프로세서는 상기 에이전트에 대한 제 1 심, 상기 에이전트에 대한 제 2 심, 상기 제 1 심에 의해 참조된 클래스들, 및 상기 제 2 심에 의해 참조된 클래스들을 로딩하는 하나 이상의 클래스 로더들을 구현하고,
상기 하나 이상의 프로세서들은 상기 제 1 심에 대한 호출들을 행하기 위해 상기 애플리케이션을 동적으로 인스트루먼트하는 하나 이상의 클래스 파일 변환기들을 구현하고,
상기 에이전트는 상기 제 1 심 및 상기 제 1 심에 의해 참조된 클래스들에 대한 상기 인스트루먼트된 애플리케이션으로부터의 호출들에 근거하여 실행되고,
상기 하나 이상의 프로세서들은 상기 에이전트에 대한 클래스 경로에 있는 코드의 소스가 록킹된 동안에 상기 애플리케이션 또는 상기 자바 가상 머신을 실행하는 동안 상기 에이전트에 대한 코드의 이전 버전을 사용하기 위해 상기 에이전트의 핫 롤백(hot roll back)을 수행하고,
상기 에이전트의 상기 핫 롤백은 상기 제 2 심에 대한 호출들을 행하기 위해 상기 애플리케이션을 동적으로 인스트루먼트하여 상기 제 2 심 및 상기 제 2 심에 의해 참조된 클래스들에 대한 상기 인스트루먼트된 애플리케이션으로부터의 호출들에 근거하여 상기 에이전트의 새로운 버전이 실행되도록 하는 것을 포함하는 것을 특징으로 하는 컴퓨팅 장치.
제15항에 있어서,
코드의 상기 제 1 저장 유닛은 상기 에이전트에 대한 클래스 경로에 있고,
상기 제 1 심에 의해 참조된 클래스들은 상기 에이전트에 대한 클래스 경로에 없는 제 1 jar 파일에 저장되고,
상기 제 2 심에 의해 참조된 클래스들은 상기 에이전트에 대한 클래스 경로에 없는 제 2 jar 파일에 저장되고,
상기 에이전트의 상기 핫 롤백은 상기 에이전트에 대한 클래스 경로에 있는 코드의 소스가 록킹된 동안 수행되는 것을 특징으로 하는 컴퓨팅 장치.
제16항에 있어서,
상기 제 1 심에 의해 참조된 클래스들은 제 1 클래스 로더에 의해 로딩되고 그리고 제 1 네임스페이스 내에 있고,
상기 제 2 심에 의해 참조된 클래스들은 제 2 클래스 로더에 의해 로딩되고 그리고 상기 제 1 네임스페이스와는 다른 제 2 네임스페이스 내에 있는 것을 특징으로 하는 컴퓨팅 장치.
제17항에 있어서,
상기 하나 이상의 프로세서들은, 부트스트랩 클래스 로더(Bootstrap Class Loader)가 상기 에이전트에 대한 제 1 코드에 액세스하는 것, 상기 부트스트랩 클래스 로더가 상기 에이전트에 대한 상기 제 1 코드를 클래스 파일 변환기에 제공하는 것, 상기 클래스 파일 변환기가 상기 에이전트에 대한 클래스 경로에 없는 소스로부터 상기 에이전트에 대한 상기 제 1 코드로 바이트 코드를 주입하는 것을 실행함으로써, 상기 제 1 심에 의해 참조된 클래스들을 로딩하는 것을 특징으로 하는 컴퓨팅 장치.
제15항에 있어서,
상기 에이전트는 자바 인스트루먼테이션 API의 자바 에이전트 옵션을 사용하여 구현되는 것을 특징으로 하는 컴퓨팅 장치.
애플리케이션을 위한 에이전트의 버전들을 관리하는 방법으로서, 상기 방법은,
에이전트에 대한 제 1 심, 상기 에이전트에 대한 제 2 심, 상기 제 1 심에 의해 참조된 클래스들, 및 상기 제 2 심에 의해 참조된 클래스들을 로딩하는 단계와;
상기 제 1 심에 대한 호출들을 행하기 위해 애플리케이션을 동적으로 인스트루먼트하는 단계와;
상기 제 1 심 및 상기 제 1 심에 의해 참조된 클래스들에 대한 상기 인스트루먼트된 애플리케이션으로부터 호출들에 근거하여 상기 에이전트를 실행하는 단계와, 여기서 상기 애플리케이션 및 상기 에이전트는 자바 가상 머신에서 실행되고;
상기 애플리케이션 및 상기 자바 가상 머신이 계속 실행되는 동안 아울러 상기 에이전트를 구현하도록 되어 있는 코드가 록킹된 동안 상기 에이전트에 대한 코드의 이전 버전을 사용하기 위해 상기 에이전트를 롤백하는 단계와,
상기 에이전트를 롤백하는 것은 상기 에이전트에 대한 클래스 경로에 있는 코드가 록킹된 동안 상기 제 2 심에 대한 호출들을 행하기 위해 상기 애플리케이션을 동적으로 인스트루먼트하는 것을 포함하고; 그리고
상기 제 2 심 및 상기 제 2 심에 의해 참조된 클래스들에 대한 상기 인스트루먼트된 애플리케이션으로부터의 호출들에 근거하여 상기 에이전트의 이전 버전을 실행하는 단계를 포함하는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제20항에 있어서,
상기 제 1 심에 의해 참조된 클래스들은 상기 에이전트에 대한 클래스 경로에 없는 제 1 jar 파일에 저장되고,
상기 제 2 심에 의해 참조된 클래스들은 상기 에이전트에 대한 클래스 경로에 없는 제 2 jar 파일에 저장되는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
제21항에 있어서,
상기 제 1 심에 의해 참조된 클래스들은 제 1 클래스 로더에 의해 로딩되고 그리고 제 1 네임스페이스 내에 있고,
상기 제 2 심에 의해 참조된 클래스들은 제 2 클래스 로더에 의해 로딩되고 그리고 상기 제 1 네임스페이스와는 다른 제 2 네임스페이스 내에 있는 것을 특징으로 하는 애플리케이션을 위한 에이전트의 버전들을 관리하는 방법.
삭제
삭제
삭제