Goal & Purpose

1. java -XX:+PrintFlagsFinal -version

2. Understanding CMS GC Logs

   https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs

3. Tomcat 정보

   톰캣설치디렉토리/bin]# ./version.sh  또는  ./catalina.sh version
   Using CATALINA_BASE:   /usr/local/tomcat/lucy_8080
   Using CATALINA_HOME:   /usr/local/tomcat/lucy_8080
   Using CATALINA_TMPDIR: /usr/local/tomcat/lucy_8080/temp
   Using CATALINA_LOGDIR: /home/www/backup/tomcatlog
   Using JRE_HOME:       /usr/local/jdk6
   Server version: Apache Tomcat/5.5.17
   Server built:   Apr 14 2006 02:08:29
   Server number:  5.5.17.0
   OS Name:        Linux
   OS Version:     2.6.9-78.ELsmp
   Architecture:   i386
   JVM Version:    1.6.0_13-b03
   JVM Vendor:     Sun Microsystems Inc.

   (이거 말고 다르게 보는 방법)
   cat RELEASE-NOTES 
   $Id: RELEASE-NOTES 351503 2005-12-01 22:12:48Z keith $
   Tomcat 5.5 is designed to run on J2SE 5.0 and later, and requires

   마이너 버젼까 확인하기 위해서는.. jar 를 풀어서.. properties를 보면 확인이 가능합니다.
   jar xf /server/lib/catalina.jar  org/apache/catalina/util/ServerInfo.properties

   grep -r 'number' org/apache/catalina/util/ServerInfo.properties
  ./org/apache/catalina/util/ServerInfo.properties:server.number=5.5.17.0

   휴지통(Recycle Bin) 에 들은 테이블 조회

   SQL> show recyclebin;

            휴지통의 모든 내용이 비워집니다.

   SQL> purge recylcebin;

            삭제된 테이블은 되사

   SQL> flashback table 테이블명 to before drop;

           만약, 특정 테이블을 휴지통에 남기지 않고 모두 삭제하려면..

   SQL> drop table 테이블명 purge;

          purge 문 없이 그냥 drop 한 후에는

   SQL> purge table 테이블명;

 

컴퓨터 전공자나 배우는 것으로 여겼던 ‘코딩’이 초등학생 ‘과외 목록’에까지 등장했다. 인문계 취업난이 갈수록 심해지자 자녀를 어려서부터 이과형 인재로 키우려는 학부모가 크게 늘었다. 정부도 2018년부터 소프트웨어 과목을 초·중학교 정규교과에 포함시키려 한다.

서울 서초구의 초등학교에 다니는 A군(10)은 매주 일요일 아침 동네 카페에서 한국과학기술원(KAIST) 학생에게 코딩 과외를 받는다. A군 학교는 지난해 교내 컴퓨터실에 애플의 매킨토시 컴퓨터 수십대를 설치하고 코딩 수업을 시작했다. 학교 수업에서는 미국 매사추세츠 공과대학(MIT) 미디어랩이 개발한 교육용 코딩 프로그램 ‘스크래치’를 쓴다. 이 수업을 따라가려면 과외가 필요했다. A군과 비슷한 처지의 초등학생이 많다보니 온라인에서는 “코딩 가르쳐줄 컴퓨터공학 전공자를 찾는다”는 학부모들의 글을 쉽게 찾을 수 있다.

10년 전 초등학교에도 컴퓨터 교육은 있었다. 하지만 워드 프로세서 등 문서 작업을 위한 프로그램 ‘사용법’을 주로 가르쳤다. 요즘 초등학생들이 배우는 코딩은 훨씬 고차원적인 프로그램 ‘제작법’이다. C언어나 자바 등 대학교 과정에나 나왔을 컴퓨터언어를 이용해 직접 프로그램을 만든다.

이런 현상은 요즘 세대의 성장 배경이 과거와 완전히 다른 데서 비롯됐다. 요즘 초등학생들은 어릴 때부터 스마트폰 태블릿PC 등 각종 전자기기에 둘러싸여 자랐다. 윗세대에 비해 컴퓨터 기술을 자연스럽게 습득하고 작동 원리를 쉽게 이해한다고 전문가들은 평가한다. 이런 세대를 가리켜 ‘테크 네이티브(Tech Native)’라는 단어까지 등장했다.

코딩 교육 열풍은 세계적인 추세이기도 하다. 영국 정부는 지난해부터 모든 초·중·고교에서 코딩을 필수 교과목으로 가르치도록 했다. 김진형 미래창조과학부 소프트웨어정책연구소장은 “어린이들에게 코딩을 가르치는 건 미래사회에 대비하는 필수 단계”라며 “다른 나라에 비해 늦은 감은 있지만 지금부터라도 국가적 역량을 키워 나가야 한다”고 말했다.

Create your first SOA Composite - Hello World ! Process

 Start JDeveloper.  Left click Applications node in the Applications Navigator and select New Application, as shown

Create an Application named Training.

Give “Training” in Application name

Select a suitable location and select SOA Application in the Application Template

The wizard now prompts you to create a project.  Later, you can add more projects to this application.

Give the project name as HelloWorld

Select Composite template as Composite with BPEL Process.  This is a convenient shortcut to tell that the composite we want to create would contain one BPEL process.  As an alternative, we can choose Empty Composite here,  add add a BPEL

 component later.

Click on Finish

A new dialog opens up.  This is to configure the BPEL component that we are adding to our composite.

Give name as HelloWorld_BPEL

Select Template as Synchronous BPEL Template and click ok.

 Templates are pre-defined structures provided by Oracle.  Essentially, by using a template, a few activities shall come by default, so that you are saved of the mundane steps of adding those activities.  It’s even possible to create your own custom templates.  As of now, we select the predefined template for a synchronous process.  A synchronous process is one which is expected to be comparatively short-lived (few seconds to minutes) and hence can be expected to return a response quite quickly.  So, the client invoking a synchronous process can afford to wait (and block) for the response to come back.

The following structure comes up.

This is the picture of the composite (more technically, it’s the design time view of composite.xml).  As you can see, it contains a servicecomponent called HelloWorld_BPEL and a binding component called helloworld_bpel_client.

Service components are the building blocks that you use to construct a SOA composite application. Examples - BPEL, Human Task, Business Rules, Mediators, Spring.

Bindingcomponentestablish a connection between a SOA composite and the external world.  They are categorized as Service binding component and Reference binding components.  Service binding components provide the entry point to the composite Reference binding components provides access to the external service in the outside

world.  Examples include JCA Adapters (FTP adapter, DB adapter, Apps adapter etc), HTTP Binding, Direct binding etc.

Double click on this component to open it up.

As you can see, there is an input coming from the helloworld_bpel_client service binding  (which represents any client that is invoking our BPEL process).  

Drag an Assign activity from the component palette on the right.

In this assign activity, we can add any number of “Copy rules”.  Copy rules allow us to copy values from a source variable to a target variable, or to assign result of an expression (say a concatenate operation or a square root operation) to a target variable.

We want to create an expression similar to

“Hello” + Input = Output.   

This we shall create using the following steps:

Expand output variable so that you can see client:result.  This is the string field to which we want to assign some value.

From the icons on top right corner, drag an expression  onto client:result.

A dialog called Expression Builder opens up.  Expression builder is a nifty tool to quickly create expressions.  It shows categories of operations.  You choose a category and it shows you the expressions within that category.   For example

Here we choose “concat” function from the String Functions category

Click on Insert into expression.  This puts the concat() into the Expression box above.  (When you get experienced, you can simply write functions directly here.).  Place the mouse cursor between “(“ and “)” of the concat function

Next we expand the input and select the client:input field.  This is the field that has got the value that was sent by the user.  We want to append hello to this and assign that to the output variable.  So choose this

Press Insert into expression

Type ‘Hello’ followed by a comma.    Note that in BPEL, (or more precisely xpath) we use single quotes for strings

Now press OK.  Control returns to Edit Assign dialog.  Now expand the outputVariablein the To section (right section) and select client:result field.  Press OK

This has completed the Assign activity.  For better readability we should always give descriptive names to activities.  

So double click on the text “Assign1” (not the icon) and give name as “Assign_Hello”  

The BPEL process is now complete !

BPEL Persistence properties are used to control, when and how a process need to be dehydrated.

1. inMemoryOptimization

This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to true, Oracle BPEL Server keeps the instances of this process in memory only during the course of execution. This property can only be set to true for transient processes (process type does not incur any intermediate dehydration points during execution).

• false (default): instances are persisted completely and recorded in the dehydration store database for a synchronous BPEL process.

• true: Oracle BPEL Process Manager keeps instances in memory only.

2. completionPersistPolicy

This property controls if and when to persist instances. If an instance is not saved, it does not appear in Oracle BPEL Console. This property is applicable to transient BPEL processes (process type does not incur any intermediate dehydration points during execution).

This property is only used when inMemoryOptimization is set to true.

This parameter strongly impacts the amount of data stored in the database (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput.

• on (default): The completed instance is saved normally.

• deferred: The completed instance is saved, but with a different thread and in another transaction, If a server fails, some instances may not be saved.

• faulted: Only the faulted instances are saved.

• off: No instances of this process are saved.

<component name="mySampleBPELComponent">
...
<property name="bpel.config.completionPersistPolicy">faulted</property>
<property name="bpel.config.inMemoryOptimization">true</property>
...
</component>

3. oneWayDeliveryPolicy

The oneWayDeliveryPolicy is from the Oracle 10g configuration property deliveryPersistencePolicy.The new configuration property name is bpel.config.oneWayDeliveryPolicy.

This property controls database persistence of messages entering Oracle BPEL Server. Its used when we need to have a sync-type call based on a one way operation. This is mainly used when we need to make an adapter synchronous to the BPEL Process.

By default, incoming requests are saved in the following delivery service database tables: dlv_message

• async.persist: Messages are persisted in the database.

• sync.cache: Messages are stored in memory.

• sync: Direct invocation occurs on the same thread.

--------------------------------------------------------------------------------------------------------------

#291 BPEL configuration properties

Rule of thumb for BPEL is - keep those processes short and sweet.
Transient, synchronous is the way to go, if possible.

ORCL docs provide for very good reading in this area - I recommend the FMW Developer Guide for SOA Suite, the FMW SOA Suite Administrators Guide as well as the FMW Performance Guide. The info below, has to a great extent, been taken from there. I also recommend AnTony Reynolds and Matt Wright's - Oracle SOA Suite 11g Developers Guide - available here

Tuning BPEL Engine Threads -

These are the guys who do the actual work -

The dspInvokeThreads property specifies the total number of threads allocated to process invocation dispatcher messages. Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance. If the majority of requests processed by the engine are instance invocations (as opposed to instance callbacks), greater performance may be achieved by increasing the number of invocation threads. Higher thread counts may cause greater CPU utilization due to higher context switching costs.


The dspEngineThreads property specifies the total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If the majority of processes deployed are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of engine threads. Note that higher thread counts can cause greater CPU utilization due to higher context switching costs.

The dspSystemThreads property specifies the total number of threads allocated to process system dispatcher messages. System dispatcher messages are general clean-up tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). Typically, only a small number of threads are required to handle the number of system dispatch messages generated during run time.

Start off with the defaults, and tune - if necessary - paying attention to the heuristics above.

These properties can be set in EM. 

As you can see, the Audit Level is set to Inherit as default. Please see my My Post on Logging for more info.

Here is the doc -

For production systems - use Production or Error - depending on your logging requirements.

Audit Detail threshold - under the threshold? - details store in the audit_trail table.
over the threshold? then audit info will be written to the audit_details table.

Large Doc Threshold - same concept -

This is the maximum size (in kilobytes) of a BPEL variable before it is stored in a separate location from the rest of the instance scope data.

Payload Validation - validates incoming and outgoing XML documents 
Incurs a performance hit.

Other Configuration properties

Now let's look at the rest -

As you can see, the descriptions shown in EM are useful and succinct.
You will not change most of these, however - some are worth investigating -


For one way invokes with possible callbacks -

Per default requests to execute a BPEL process are written to the soa_infra.dlv_message table - this causes a message to be generated that is then picked up by a worker thread which then starts executing the process.

Big benefit - Reliability no requests get lost - however we do have an extra DB write.

If set to async.cache then the request is cached in-memory - better Performance

If set to sync -> queuing is bypassed, and the BPEL process is invoked synchronously.
Client has full control of what happens.


1. bpel.config.oneWayDeliveryPolicy
Default value specified in MBean - accessible from em

async.persist: Messages are persisted in the database hash map.
sync.cache: Messages are stored in memory.
sync: Direct invocation occurs on the same thread.

Can be overwritten in the BPEL process definition in composite.xml -

onewayDeliveryPolicy=sync
and
transaction=required
BPEL process runs in the same thread and the same transaction.

onewayDeliveryPolicy=sync
and
transaction=requiresNew
BPEL process runs in the same thread but within a new transaction.

completionPersistPolicy

Here you need to ask yourself, whether the instance data needs to be persisted, and if so to what extent.
If your BPEL process integrates System A with System B. then the fact that the data has been successfully written to B suffices.

Simple example -

here is my one-way BPEL process that writes its input to a file -

Test - here is the output order.

Here is the em trace -

Now I set the the completePersistPolicy to off in composite.xml -
I also need to set inMemoryOptimization = true

Re-test - my output file has been written.

Check the audit trail in em -

Probably faulted would be the best setting here.

The SyncMaxWaitTime property sets the maximum time the process result receiver
waits for a result before returning. Results from asynchronous BPEL processes are
retrieved synchronously by a receiver that waits for a result from Oracle BPEL Server.
The default value is 45 seconds.

If you have sync BPEL processes and you see the need to up this property, then consider making the processes async.

MaxRecoverAttempt - number of times to attempt recovery of invoke/callback messages.

The recovery behavior for invoke and callback messages is different when
MaxRecoverAttempt is set. For example, assume MaxRecoverAttempt is set to 4.
■ Invoke message recovery is retried 4 (N) times before moving the message to
the exhausted state.
■ Callback message recovery is retried 5 times (N + 1) before moving the
message to the exhausted state.
This is the expected behavior. The first attempt is not counted as a recovery
attempt. The recovery attempts are incremented by the BPEL process service
engine. If MaxRecoverAttempt is set to 1, you see one default resolution process
and then one recovery attempt.

Recovery Configuration

This feature is detailed in the Administrator’s Guide for Oracle SOA Suite and Oracle
Business Process Management Suite


e.g. We are trying to update a DB and it is temporarily unavailable.

This covers -
All activities (for example, wait activities and OnAlarm branches of pick activities)
that have an associated expiration date and are scheduled with the SOA
Infrastructure to be rescheduled
■ All activities that are not complete over a provided threshold time

■ All invoke and callback messages that are unresolved

When should auto-recovery be available?
Check out the RecurringScheduleConfig - set start/stopWindowTime

Check out StartupScheduleConfig -
the default config tells us -

maxMessageRaiseSize The maximum number of messages to submit for each startup
recovery attempt. Use this property to limit the impact of recovery on the server. This value specifies the maximum number of messages to filter from activity, invoke, and callback
queries; that is, 50 messages from each of the activity, invoke, and callback tables.

startupRecoveryDuration -
Specifies the number of seconds that the startup recovery period
lasts. After the server starts, it goes into a startup recovery
period. During this period, pending activities and undelivered
callback and invocation messages are resubmitted for
processing.
The default value is 600 (ten minutes). A negative or zero value
disables startup recovery.

 

Partner Link Properties

The main ones ares -

nonBlockingInvoke=true
PartnerLink Service will executed in a separate transaction.

idempotent=false
Executes on same Thread/transaction

 

JBoss Commnunity 에서 다운로드 한 JBoss 기본 로깅 레벨은 DEBUG 입니다.

구동 시간도 오래 걸리고 로그 메시지도 DEBUG가 추가되므로 보기 힘듭으로 JBoss 설치 후 반드시 기본 로깅 레벨 변경이 필요

<JBOSS_HOME>/server/<CONFIGURATION>/conf/jboss-log4j.xml 파일을 편집기로 열어서 보면 JBoss 5부터 Threshold가 추가되어 있는데 이 옵션의 실제 기본값은 DEBUG 입니다. 따라서 이 값을 변경해주면 기본 로깅 레벨을 변경할 수 있습니다.

※ 참고사이트 : http://cafe.naver.com/jbossug/1327

When working with large (server side) java application, sometimes it would be nice if you could look inside, to see what thread is taking up so much cpu time, and why. Something similar to the Unix top command, but then showing all threads in one (java) application, instead of all processes in the system.

When I was looking for such a monitoring application, I came accross the 2.0 version of MC4J that provides a “Thread Info” panel that displays threads together with CPU usage; exactly what I needed. Unfortunately, there is only an alpha release of this MC4J version, that is not yet perfectly stable. Moreover, the thread info panel doesn’t handle applications with large amounts of threads very well. As the source code of this version of MC4J is not (yet) publically available, this option turned out to be a dead end.

To my surprise, other applications with such functionality are hard to find. There are probably enough profiling applications that can do the job, but I wanted something simple, something JMX-based, that can used also to monitor applications running in production.

There is however something called JTop, which is a plugin for JConsole. It’s actually a demo for the new (since Java 6) JConsole plugin API, that does show CPU usage per thread. It’s fairly basic and only shows total CPU usage, which is not very usefull. You would expect that (after a year), somebody would have extended the demo to something more useful, but as I couldn’t find anything like that, I thought I should give it a try myself.

The result is a JConsole plugin that displays the top threads, sorted by cpu usage in the last sampling period. It also displays cpu usage history, and an average over the last 10 sampling periods.

To avoid ending up with an unresponsive user interface when monitoring applications with large number of threads, I took a few precautions. First of all, the plugin has it’s own refresh rate. It’s independent from the JConsole poll interval, which is 4 seconds by default. For applications with large amounts of threads, this is way too short: only retrieving all thread information can already take 4 or 5 seconds! Although you can change the JConsole poll interval with a command line option, I thought it would be more convenient to be able to change it from the monitoring panel. It’s default set to 10 seconds, which I think is reasonable in most cases. If you notice that cpu usage measurement takes too much of the application under test, just increase the sample period and see the RMI Connection thread that processes these request, sink in the list.

Another precaution was not to list all threads in the table. Displaying thousands of rows in a table is quite useless in any case, and I was afraid it would seriously harm performance. Eventually, diplaying that many rows turned out to be not much of a problem; I guess I still suffer from an prejudice with
respect to Swing performance…

Using MX4J also showed me that in a continuously refreshing table, it’s hard to select a thread in order to see it’s stacktrace. Therefore, in this plugin, tracing a thread is “sticky”: when you click a row in the table, the stacktrace of that thread is shown immediately and is refreshed with each new sample, until you deselect it or select another thread.

Even though having threads sorted by cpu usage is the logical thing to do, it’s not always convenient when you’re studying the results, as rows keeping moving with each refresh. To lock the rows to there current position, click the “fix order” button. The topmost rows (actually all rows with a non-zero cpu usage), will stay where they are. Rows that had a cpu usage of zero, but have a non-zero value in the next sampling periods, will appear just below these rows, to avoid that you oversee any thread that suddenly takes a large amount of cpu time.

You can run the plugin by downloading the jar-file and passing it to JConsole with the plugin option:
jconsole -pluginpath topthreads.jar. When JConsole connects, it should have a seventh tab named “top threads”.