'분류 전체보기' 카테고리의 글 목록 (56 Page)

JBoss 시작/종료 스크립트

WEB/JBossAS / 2010. 5. 23. 02:37

기본 환경의 시작 스크립트

#!/bin/sh
############################################
## On default, to launch JBoss
############################################
nohup ./run.sh -b 192.168.0.11 > /dev/null &

기본 환경의 종료 스크립트

#!/bin/sh
############################################
## On default, to kill JBoss
############################################
ps -ef | grep "/usr/local/jboss5/bin/run.jar" | grep -v grep | awk '{ printf("ProcessID %s Terminated.\n", $2); }'
ps -ef | grep "/usr/local/jboss5/bin/run.jar" | grep -v grep | awk '{ printf("kill -9 %s\n", $2); }' > tmp.$$
sh tmp.$$
rm -f tmp.$$

클러스터링 환경의 시작 스크립트

#!/bin/sh
############################################
## On node1, to launch JBoss
############################################
nohup ./run.sh -c node1 -g vickiPartition -u 239.255.100.100 -b 192.168.0.11 -Djboss.messaging.ServerPeerID=1 -Djboss.service.binding.set=ports-default -Djboss.server.log.dir=/home/vicki/logs/node1 > /dev/null &

클러스터링 환경의 종료 스크립트

#!/bin/sh
############################################
## On node1, to kill JBoss
############################################
ps -ef | grep "ServerPeerID=1" | grep -v grep | awk '{ printf("ProcessID %s Terminated.\n", $2); }'
ps -ef | grep "ServerPeerID=1" | grep -v grep | awk '{ printf("kill -9 %s\n", $2); }' > tmp.$$
sh tmp.$$
rm -f tmp.$$

클러스터링 환경에서는 프로세스가 두 개가 뜨기 때문에 종료 스크립트가 있는 것이 편리합니다. 그렇지 않고 JBoss 에서 제공되는 종료 스크립트를 이용할 경우 바로 프로세스가 떨어지지 않아 사용자의 요청이 종료 중이 프로세스로 갈 수도 있습니다. 바로 프로세스를 죽이는 것이 운영 중에는 좋습니다.

클러스터링 환경에서 시작 스크립트 테스트

[root@localhost bin]# ./run.node1.sh
[root@localhost bin]# ps -ef | grep jboss
root      3123     1 0 11:32 pts/0    00:00:00 /bin/sh ./run.sh -c node1 -g vickiPartition -u 239.255.100.100 -b 192.168.0.11 -Djboss.messaging.ServerPeerID=1 -Djboss.service.binding.set=ports-default -Djboss.server.log.dir=/home/vicki/logs/node1
root      3146 3123 60 11:32 pts/0    00:00:01 java -Dprogram.name=run.sh -server -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/usr/local/jboss5/lib/endorsed -classpath /usr/local/jboss5/bin/run.jar org.jboss.Main -c node1 -g vickiPartition -u 239.255.100.100 -b 192.168.0.11 -Djboss.messaging.ServerPeerID=1 -Djboss.service.binding.set=ports-default -Djboss.server.log.dir=/home/vicki/logs/node1
root      3158 3086 0 11:32 pts/0    00:00:00 grep jboss

실제로 프로세스를 실행 시키면 위와 같이 jboss 와 관련된 프로세스 2개를 확인할 수 있습니다. 한 서버에 두 개의 인스턴스가 있을 경우 구분할 수 있는 것은 ServerPeerID 이기 때문에 실행 스크립트에서 "ServerPeerID=1" 를 사용하였습니다.

클러스터링 환경에서 종료 스크립트 테스트

[root@localhost bin]# ./stop.node3.sh
ProcessID 3123 Terminated.
ProcessID 3146 Terminated.

저작자표시

Posted by 자수씨

, |

JBoss 5.1.0 GA 클러스터링 - 2 Nodes on Multi-Servers

WEB/JBossAS / 2010. 5. 23. 02:24

실제로 서비스를 하는 운영환경이라면 WAS 서버를 여러 대를 두어 가용성을 높일 수도 있습니다.

이러한 경우에는 L4 스위치가 로드 밸런싱을 하도록 구성되는 경우가 많습니다.

[그림 1] 2 Nodes on Multi-Servers 구성도

[그림 1] 의 구성은 L4 스위치가 두 개의 HTTP Server 앞단에서 로드밸런싱을 수행하며, 각 서버마다 두 개의 WAS 노드(인스턴스) 가 있습니다. 이와 같은 구성을 위해 앞에서 소개했던 클러스터링에서 몇 가지의 추가적인 설정이 필요로 합니다.

JBoss 의 노드(인스턴스) 구성은 node3, node4 로 설정된다는 점과 실행 옵션에서 -Djboss.service.binding.set=ports 의 값이 node3 은 ports-default, node4 는 ports-01 이라는 점만 유념하시면 됩니다.

실제로 가장 중요한 부분은 Apache HTTP Server 의 workers.properties 설정입니다.

<APACHE_HOME>/conf/workers.properties

# Define list of workers that will be used
# for mapping requests
worker.list=loadbalancer,status

# Define Node1
worker.node1.port=8009
worker.node1.host=192.168.0.11
worker.node1.type=ajp13
worker.node1.lbfactor=1
worker.node1.cachesize=10

# Define Node2
worker.node2.port=8109
worker.node2.host=192.168.0.11
worker.node2.type=ajp13
worker.node2.lbfactor=1
worker.node2.cachesize=10

# Define Node3
worker.node3.port=8009
worker.node3.host=192.168.0.12
worker.node3.type=ajp13
worker.node3.lbfactor=1
worker.node3.cachesize=10

# Define Node4
worker.node4.port=8109
worker.node4.host=192.168.0.12
worker.node4.type=ajp13
worker.node4.lbfactor=1
worker.node4.cachesize=10

# Load-balancing behaviour
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2,node3,node4
worker.loadbalancer.sticky_session=1
#worker.list=loadbalancer

# Status worker for managing load balancer
worker.status.type=status

각 서버의 Apache HTTP Server 설정을 위와 같이 바꾸어주면 자신의 서버에 올려져 있는 인스턴스 뿐만 아니라 다른 서버의 인스턴스까지 요청이 가능하게 됩니다.

단, 이러한 구성의 경우 세션 복제로 인한 오버헤드가 발생할 수 있습니다. buddy-replication 설정을 통해 근접한 인스턴스에게만 세션 복제를 할 수 있게 설정할 수 있습니다.
node1 -> node2, node2 -> node3, node3 -> node4, node4 -> node1 이런 방식으로 buddy-replication 을 설정하면 하나의 노드가 죽더라도 buddy 노드가 해당 세션을 복제 받을 수 있을 것 입니다. 하지만 이러한 경우 sticky-session 설정이 되어야 할 것으로 생각되네요...

쉬울지 알고 접근했던 JBoss 클러스터링인데, 역시 뭐든지 실제로 해보고 느껴봐야 할 것 같습니다.
안해봤으면 말을 하지 마요~ 어후...

저작자표시

Posted by 자수씨

, |

JBoss 5.1.0 GA 세션 클러스터링

WEB/JBossAS / 2010. 5. 23. 00:33

JBoss 에서 고가용성(High Availability) 환경을 구성하기 위해서는 세션 클러스터링이 필요합니다.

테스트에 사용된 환경은 다음과 같습니다.
System: VMWare
OS: CentOS 5.5 x86-64
HTTP Server: Apache HTTP Server 2.2.3
WAS: JBoss 5.1.0 GA

[그림 1] 서버 구성

위의 [그림 1] 에서 보는 것 처럼 하나의 시스템에 하나의 Apache HTTP Server 와 두 개의 JBoss Web Application Server 로 구성할 것 입니다.

kr.co.vicki.test.jboss.UserInfo.java
package kr.co.vicki.test.jboss; import java.io.Serializable; public class UserInfo implements Serializable { private static final long serialVersionUID = -3224515083286995928L; private String id; private String name; private String empno; private String serverPeerID; public String getId() { return id; } public void setId(String id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getEmpno() { return empno; } public void setEmpno(String empno) { this.empno = empno; } public String getServerPeerID() { return serverPeerID; } public void setServerPeerID(String serverPeerID) { this.serverPeerID = serverPeerID; } }

/createSession.jsp
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@page import="kr.co.vicki.test.jboss.UserInfo"%> <% String id = request.getParameter("id"); String name = request.getParameter("name"); String empno = request.getParameter("empno"); UserInfo userInfo = new UserInfo(); userInfo.setId(id); userInfo.setName(name); userInfo.setEmpno(empno); userInfo.setServerPeerID(System.getProperty("jboss.messaging.ServerPeerID")); session.setAttribute("userInfo", userInfo); %> <html> <body> <h2>세션생성</h2> <table> <tr> <td>ServerPeerID</td> <td><%=System.getProperty("jboss.messaging.ServerPeerID")%></td> </tr> <tr> <td>id</td> <td><%=userInfo.getId()%></td> </tr> <tr> <td>name</td> <td><%=userInfo.getName()%></td> </tr> <tr> <td>empno</td> <td><%=userInfo.getEmpno()%></td> </tr> <tr> <td>serverPeerID</td> <td><%=userInfo.getServerPeerID()%></td> </tr> </table> <a href="viewSession.jsp">세션보기</a> </body> </html>

/viewSession.jsp
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@page import="kr.co.vicki.test.jboss.UserInfo"%> <% UserInfo userInfo = (UserInfo) session.getAttribute("userInfo"); %> <html> <body> <h2>세션확인</h2> <table> <tr> <td>ServerPeerID</td> <td><%=System.getProperty("jboss.messaging.ServerPeerID")%></td> </tr> <tr> <td>id</td> <td><%=userInfo.getId()%></td> </tr> <tr> <td>name</td> <td><%=userInfo.getName()%></td> </tr> <tr> <td>empno</td> <td><%=userInfo.getEmpno()%></td> </tr> <tr> <td>generateServerPeerID</td> <td><%=userInfo.getServerPeerID()%></td> </tr> </table> </body> </html>

/createSession.jsp?id=vicki&name=vicki&empno=99999 로 요청 시

첫번째 인스턴스에서 세션이 생성되었음을 확인할 수 있습니다.

같은 브라우저에서 /viewSession.jsp 로 요청 시

인스턴스 1 에서 생성된 세션을 인스턴스 2 에서 확인할 수 있습니다.

다시 한번 요청하면 라운드 로빈 방식의 로드 밸런싱에 의해 1번 인스턴스로 요청을 하게 됩니다.

failover 테스트를 위해 인스턴스 1 을 종료하게 되면 모든 요청이 인스턴스 2 로 가게 됩니다.

이로써 클러스터링 (로드밸런싱 + failover) 테스트를 완료하였습니다.

어떻게 보면 테스트 환경은 쉽게 구성될 수 있지만, 실제로 운영환경에서는 각 설정값을 변경해주어야 재대로 성능을 발휘할 수 있습니다. 그리고 방화벽이 있는 경우 세션 복제를 위한 멀티캐스트 송수신이 정상적으로 안될 수도 있습니다.

간단한 웹 어플리케이션이 포함된 JBoss 인스턴스 하나 띄우는데 메모리가 600 메가 정도 사용하는 것 같습니다. 한 시스템에 2개의 인스턴스를 띄우려면 적어도 인스턴스당 1.5 기가의 메모리가 필요하지 않을까 생각이 됩니다.

이외에도 많은 변수가 있기에 실제 운영 환경에 배포하기 위해서는 많은 공수가 들 것으로 생각됩니다.

참고자료
http://www.jboss.org/file-access/default/members/jbossclustering/freezone/docs/cluster_guide/5.1/pdf/Clustering_Guide.pdf
http://community.jboss.org/wiki/ConfigurationChangesforClusteredWebApplicationsinAS5
http://www.datadisk.co.uk/html_docs/java_app/jboss5/jboss5_clustering.htm

저작자표시

Posted by 자수씨

, |

안정적인 조직에 대해 생각해 봅니다 - 객체지향적 조직?

주절주절 / 2010. 5. 22. 01:45

하나의 조직에는 여러 구성원들이 있습니다. 조직이 팀이라고 한다면 크게는 팀장과 팀원들으로 나눌 수 있습니다. 만약헤 팀원의 수가 많다면 팀장 혼자서 관리하기 힘들게 될 것 입니다. 이러한 경우에는 팀을 여러 파트로 나누어서 파트장-파트원들로 구성될 것 입니다.

팀이 파트로 나누어 질 때는 파트장만 혼자 있는 파트가 너무 많아서 파트원의 수보다 파트장들이 많으면 불필요한 관리포인트가 늘어나게 될 것 입니다. [그림 1] 과 같이 파트원이 가장 많은 규모를 차지하는 것이 안정적인 구성이라고 할 수 있을 것 입니다.

[그림 1] 조직(팀)의 안정적인 구성

일단 파트장이 된 팀원은 파트원을 관리해야 하는 관리적인 롤을 부여받게 됩니다. 중간관리자인 파트장은 기존에 자기가 맡고 있던 업무외에 추가적으로 관리적인 측면도 신경을 써야하는 것 입니다. 모든 회사가 그렇지는 않겠지만 파트장이 되면 여러 혜택들을 지원해 줄 것 입니다. 이것은 단순히 파트장이여서 주는 것이 아니라 자신의 파트원을 관리해야하는 책임을 부여했기 때문입니다.

가장 우선시 되는 파트장의 관리 포인트는 파트원의 리소스 관리입니다. 리소스 관리를 위해서는 파트원의 역량에 대해 미리 파악하고 있어야 하며, 일정을 수시로 확인해야 할 것 입니다. 이런 것들이 준비가 되어있지 않다면 위에서 내려오는 지시에 대해 파트 내에서 업무분담이 어렵게 됩니다. 아래로 일을 내리지 못하면 파트장 자신이 힘들게 되며, 파트원들의 리소스를 고려하지 않고 아래로 일을 내리게 되면 파트원들이 힘들게 될 것 입니다. 파트장이 파트원들을 위해 해야할 일은 파트원들이 힘들까봐 혼자서 일을 다 해주는 것도 이나고, 파트원들에게 맛있는 것을 사주는 것도 아닙니다. 자신의 파트에서 처리할 수 있는 업무를 할당받아 파트원들이 그 업무를 나누어 처리하는 것 입니다. 파트원들의 역량이 똑같을 수는 없습니다. 어느 한 부분에 강점이 있으면 다른 부분에 약점이 있을 것 입니다. 파트원들의 역량 및 장단점을 파악하여 업무를 분배하는 것도 파트장의 몫입니다. 위에서 내려오는 지시에 대해 파트의 역량내에 커버가 가능한 정도로 협의와 조율을 해야하는 것도 파트장의 중요한 업무입니다. 그외에도 파트원에게 직접 내려오는 지시사항을 자신을 통해서 들어오도록 프로세스를 만들어가야 합니다. 이런 파트장이 파트원들과 신뢰를 바탕으로 업무를 할 수 있는 것 입니다. 그렇다고 무작정 파트장이 파트원을 감싸는 것이 능사는 아닙니다. 파트원이 능력이 부족할 경우 여러 번의 기회를 주어 함께 업무를 진행할 수 있는지를 파악하고 조치를 취하는 것이 파트를 위해서도 필요할 것 입니다. 신뢰를 바탕으로 유기적으로 돌아가는 파트는 팀에 활력소를 불어넣을 수 있을 것 입니다. 파트가 성장하면 조직도 성장하게 될 것 입니다. 결론적으로 파트장은 자신의 파트를 캡슐화하여 위에서 보았을 때 하나의 개체로 인식시키는 것 입니다.

이런 파트장을 만드는 것은 파트장 혼자가 움직인다고 되는 것이 아닙니다. 팀장은 파트장에게 힘을 실어주어야 파트장의 위신을 세워줄 수 있으며 파트장 자신에게 책임감을 부여할 수 있을 것 입니다. 파트원들도 파트장이 결정한 사항에 대해 마음에 들지 않을 수 있습니다. 또, 파트장이 항상 옳은 결정을 한다고 볼 수도 없습니다. 이렇다고 해서 불만을 제기하게 되면 파트 내에 신뢰를 구축하기가 어렵게 됩니다. 파트에 대해 함께 고민할 수 있는 조언자가 되어야 합니다. 그리고 보고 체계를 무시하고 바로 팀장에게 보고하는 것은 파트장이 파트를 운영하는데 도움이 되지 않습니다. 파트를 캡슐화 해야하는 것이 파트장의 목적 중에 하나인데 직접적으로 팀장과 업무 협의를 하는 것은 파트장에게 곤란한 상황을 만들 수 있는 계기가 될 수도 있습니다.

[그림 2] 에서 보이는 것 처럼 팀장이 모든 팀원을 관리하게 되면 정작 본인이 관리해야 할 업무보다 더 많은 양을 감수해야할 것입니다. 안정적인 조직이 되기 위해서는 팀장은 [그림 3] 과 같이 파트장들만 보며 관리할 수 있는 조직이 되어야 할 것 같습니다.
결국 팀장도 회사 전체로 보았을 때는 중간관리자입니다. 본부장이 자신의 본부에 속해있는 본부원 개개인에게 관심을 쏟을 수 없듯이 팀장도 모든 팀원들에게 관심을 쏟을 수 없습니다.

[그림 2] 캡슐화되지 않은 팀 구성

[그림 3] 캡슐화된 팀 구성

한 가족 처럼 묶일 수 있는 가장 큰 단위인 팀이 안정적인 조직으로 발돋움 하기 위해서는 팀의 중간관리자인 파트장의 역할이 가장 중요하다고 생각됩니다.

이전부터 생각하던 내용을 글로 쓰다보니 처음에 의도했던 것과는 다른 글들이 쓰여지는 것을 보고 "아... 나는 글쓰기에 소질이 없구나" 를 깨달았습니다. 그래도 여러번 쓰다보면 다듬어 질 것이라 생각을 하며 평소 생각을 정리하려고 합니다.

저작자표시

Posted by 자수씨

, |

JBoss 5.1.0 GA 배포 디렉토리 추가하기

WEB/JBossAS / 2010. 5. 21. 22:01

JBoss 의 배포 경로를 "D:\Server\webapps" 도 추가하려면 JBoss 설정을 변경합니다.

<JBOSS_HOME>/server/<CONFIGURATION>/conf/bootstrap/profile.xml 를 열어 하일라이팅 된 부분과 같이 경로를 추가합니다.



	...
	
	
	
		${jboss.server.home.url}conf/bindingservice.beans
		${jboss.server.home.url}conf/jboss-service.xml
		${jboss.server.home.url}deployers
		
			
				${jboss.server.home.url}deploy
				file://D:/Server/webapps
			
		
		${jboss.server.data.dir}/attachments
		
	

	...

-_-;; syntax highlight 가 좀 이상해서 element 가 대문자로 표시가 되네요;;; 쿨럭;;;

정리 차원에서...

참고자료: 우리 회사 데모서버, http://cafe.naver.com/jbossug.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=2081

저작자표시

Posted by 자수씨

, |

이제부터 저녁 밥은 닭가슴살인거다!!!

쇼핑노트/It's mine / 2010. 5. 20. 17:52

디어어트를 위해 주문한 "하림 웰 닭가슴살 캔" 이 배송되었습니다.

열량은 95kcal 입니다. 총 용량이 80g 인데 단백질보다 나트륨이 더 많네요 ㅋㅋㅋㅋㅋ 왜 나트륨은 mg 으로 표시한건지;;;

작은 참치캔 크기라고 보시면 됩니다.

유통기한은 넉넉하게 2015 년 까지라서 문제는 없을 것으로 생각됩니다.

이제 두 달 정도 저녁밥으로 먹게될 닭가슴살...

다행히 원래 닭가슴살을 좋아해서 질릴 염려는 없는데, 꾸준하게 먹을지가 의문이네요~

저작자표시

Posted by 자수씨

, |

오랜만에 코스트코 나들이~

쇼핑노트 / 2010. 5. 18. 11:54

운규누나 집들이 선물도 살겸 작은누나를 꼬셔 양평동 코스트코를 다녀왔습니다.

켈로그 스페샬 K 레드베리
돌아다니는데 할인행사를 하고 있었습니다. 냉큼 집어왔습니다. 12,790 원??? 으로 기억됩니다.

두 봉지가 들어 있습니다. 무게는 1.05kg 입니다.

GDA 기준으로 2000 칼로리를 다이어트 할 수 있다는 소리인가요... 영어 까막눈이라...

100g 에 387 Kcal 입니다. 으흠... 생각했던 것 보다는 칼로리가 높은 것 같네요;;;

무스까또 다스티
제가 제일 좋아하는 스파클링 와인입니다.

2008년 산입니다.

5도 짜리 무난한 와인입니다.

봄베이 사파이어
오늘의 주인공 봄베이 사파이어입니다. 이걸 사러 코스트코에...

봄베이 사파이어 드라이 진~

47도의 강력한 파워가~~~

크크크... 누굴 죽일지 고민중입니다만... 집들이 선물이기 때문에...

수입품인가???

코스트코에서 21만원이나 긁고 마음도 함께 긁혔습니다.

내돈.... 또 카드값 160 나오는 건 아닐지 조마조마 합니다...

저작자표시

Posted by 자수씨

, |

대진옹 복귀!!!

취미생활/야구 / 2010. 5. 16. 19:09

기아타이거즈 몇몇 선수들의 모자와 헬멧에는 45라고 적혀 있는 숫자가 있습니다.

기아의 45번은 바로 대진옹!!! 이대진 선수입니다. 선수들은 부상 때문에 시즌 초 합류하지 못하였지만 그 번호를 어딘가에 새겨두고 대진옹의 복귀를 염원했던 것 같습니다.

5월 16일, 오늘!!! 로페즈를 이어서 두번째 투수로 올시즌 첫 등판을 하였습니다.

지금 1:5 로 지고 있는 상태이지만 대진옹의 복귀가 더 기분이 좋습니다.

후후훗~

저작자표시

Posted by 자수씨

, |

집에서 꾸이맨 처럼 쥐포 만들어 먹기~

주절주절 / 2010. 5. 15. 12:26

인터넷 서핑 중에 눈에 띄어 쥐포를 사게 되었습니다.

한팩에 2,500 원 입니다. 10장이 들어있네요~

이제부터 준비 시작입니다.

해피콜 누룽지팬을 약불에 달굽니다.

쥐포 한 장을 살포시 올려놓습니다.

누룽지 팬을 닫고 5~10초 간격으로 뒤집어 가며 굽습니다. 크기가 커지더라도 놀라지마세요~ 곧 줄어드니까요.

평평한 접시에 옮겨서 뒤집게로 눌러줍니다. 눌러주지 않으면 모양이 프리스타일이 되어버려서...

10 장 다 구워버렸습니다. 시간은 10분도 안 걸리네요.

해피콜 누룽지팬은 여러용도로 사용이 가능합니다. ㅎㅎㅎ

저작자표시

Posted by 자수씨

, |

이클립스에서 Web Services Client 생성 시 HTTP Authentication 처리

JAVA/WebServices / 2010. 5. 13. 21:46

웹 서비스 클라이언트를 가장 빨리 테스트 할 수 있는 방법은 이클립스에서 Apache Axis 를 이용한 클라이언트를 제너레이션 하여 테스트하는 것 입니다.

하지만 HTTP Authentication 인증 처리는 자동화해주지 않기 때문에 제너레이션된 소스에 별도의 수정이 필요합니다.

생성된 클래스 중 [ServiceName]Location.java 파일이 있을 것 입니다.
저의 경우에는 WorkflowWebServices 가 serviceName 이기 때문에 WorkflowWebServicesLocator.java 파일을 수정하였습니다.

getWorkflowWebServicesPort(java.net.URL portAddress) 메소드에서 생성된 stub 에 username 과 password 프로퍼티를 설정하는 것입니다.

_stub._setProperty(_stub.USERNAME_PROPERTY, "vicki");
_stub._setProperty(_stub.PASSWORD_PROPERTY, "vickivicki");

위와 같이 username 과 password 를 설정하면.... HTTP 인증 절차도 통과가 됩니다.

유후~~

오늘 웹 서비스만 너무 많이 파고 들어간거 같네요... 힘이 듭니다. 털썩...

저작자표시

Posted by 자수씨

, |

Jboss options
-c	configuration 을 설정하는 것 입니다. all 을 통해 복사한 node1, node2 를 각 인스턴스별로 설정합니다.
-g	클러스터 이름을 설정합니다. (그냥 자기가 좋아하는 이름을 지정하면 될 것 같습니다.)
-u	내부 클러스터 통신을 위한 멀티캐스트 주소를 설정합니다.
-b	소켓에 바운딩될 아이피 주소를 설정합니다.

System properties
jboss.messaging.ServerPeerID	각 노드마다 지정되는 유니크한 정수 값 입니다. 1부터 순차적으로 증가하면 될 것 같습니다.
jboss.service.binding.set	ServiceBindingManager 를 통해 포트 설정을 위한 프로퍼티입니다. 시스템별 첫번째 인스턴스에는 ports-default 로 설정하고 그 다음 인스턴스부터는 ports-01, ports-02 ... 과 같이 설정을 합니다. 기본적으로 JBoss 의 포트가 8080 이고 AJP 1.3 포트가 8009 라면 ports-default 는 8080, 8009 로 바인딩 되고, ports-01 은 8180, 8109 로 바인딩 됩니다.

불친절한자수씨

카테고리

달력

공지사항

최근에 올라온 글

최근에 달린 댓글

'전체글'에 해당되는 글 1457건

JBoss 시작/종료 스크립트

JBoss 5.1.0 GA 클러스터링 - 2 Nodes on Multi-Servers

JBoss 5.1.0 GA 세션 클러스터링

안정적인 조직에 대해 생각해 봅니다 - 객체지향적 조직?

JBoss 5.1.0 GA 배포 디렉토리 추가하기

이제부터 저녁 밥은 닭가슴살인거다!!!

오랜만에 코스트코 나들이~

대진옹 복귀!!!

집에서 꾸이맨 처럼 쥐포 만들어 먹기~

이클립스에서 Web Services Client 생성 시 HTTP Authentication 처리

글 보관함

최근에 받은 트랙백

링크

티스토리툴바