- 浏览: 821797 次
- 性别:
- 来自: 北京、四川
文章分类
最新评论
-
sunbeamzheng:
总结的很好,好好看看。 拷贝问题确实很需要注意,特别是影不影响 ...
java深拷贝与浅拷贝 -
xmh8023:
...
获取POST数据的值 -
xmh8023:
我访问别的服务器怎么办?急求
获取POST数据的值 -
xmh8023:
String urlString="http://l ...
获取POST数据的值 -
lv12312:
Tomcat 7的老版本么?有bug的,https://iss ...
JMX问题
oscache集群配置参数说明
url:http://www.cs.cornell.edu/Info/Projects/JavaGroupsNew/userguide/html/user/index.html
这里使用默认的cache.event.listeners=com.opensymphony.oscache.plugins.clustersupport.JavaGroupsBroadcastingListener
oscache集群的默认配置如下:
UDP(mcast_addr=231.12.21.132;mcast_port=45566;ip_ttl=32;\
mcast_send_buf_size=150000;mcast_recv_buf_size=80000):\
PING(timeout=2000;num_initial_members=3):\
MERGE2(min_interval=5000;max_interval=10000):\
FD_SOCK:VERIFY_SUSPECT(timeout=1500):\
pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800;max_xmit_size=8192):\
UNICAST(timeout=300,600,1200,2400):\
pbcast.STABLE(desired_avg_gossip=20000):\
FRAG(frag_size=8096;down_thread=false;up_thread=false):\
pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=true)
FD
The failure detection layer (FD) periodically tries to reach its nearest neighbor to the right
Figure 7.1: Failure detection layer
The nearest neighbor is always computed based on the local view. Since all views in all stacks have the same member ordering, every member can always determine its next neighbor to the right. When a new view is received, the neighbor is recomputed.
The FD layer periodically pings its neighbor. When no response has been received after max_tries (each with a timeout), a SUSPECT message is multicast to all members of the group. The GMS layer which is currently the coordinator processes the message, all others ignore it7.1. In the example, the coordinator would be A. It pings B which in turn pings C. The last member ( E) 'wraps around' and pings the first (A).
FRAG(the fragmentation protocol layer)
It essentially breaks up bigger messages into smaller ones and reassembles them at the receiver's side.
GMS
The group membership service is probably the most important protocol layer, and also the most complex to implement. The description is based on the current (March 99) GMS layer, but work is underway to replace this layer with a new one (RpcGMS).
When a CONNECT event is received by the GMS layer, it tries to join the group. To do so, it first tries to retrieve the initial membership. If no other members can be found, it assumes it is the first member and sends a VIEW_CHANGE event up/down the stack. Otherwise, it determines the coordinator and sends a unicast message to the latter to join it to the group. The coordinator adds the new member to its local view and multicasts the new view to all GMS layers, which then in turn generate VIEW_CHANGE events up/down the stack.
When a member wants to leave a group, it disconnects from the channel. This causes a DISCONNECT event to be sent down where it is caught by the GMS layer. The latter sends a unicast LEAVE request to the coordinator, which in turn removes the member from its local view and multicasts the new view.
When a SUSPECT event is received by the GMS layer, if the layer is the current coordinator, the member will be removed from the local view and a new view multicast to all members. Otherwise, the event is just dropped. In case the suspected member is the coordinator itself, the next member of the group in order takes over and multicasts a new view (excluding the old coordinator).
PING
The PING layer is responsible for finding the initial membership of a group. It does so upon reception of a FIND_INITIAL_MBRS event (sent by the GMS layer). When done, a FIN_INITIAL_MBRS_OK event is sent up the stack, containing the members found as argument. GMS waits until it receives the initial membership, and - based on it - determines the current coordinator to which it then sends a join request. When not receiving the initial members within a certain time frame, a timeout is received, and the GMS creates a singleton group (with itself as only member).
Currently the initial membership is found either using a multicast to an IP multicast address to which all members respond, or using the Router daemon (see 3.8.1), if IP multicast is not enabled.
UDP
UDP is currently the bottommost layer available to use in a protocol stack.
When it receives a START event (upon channel connection), it creates a unicast and an IP multicast socket. The IP address plus the port number of the unicast socket form the channel's address: every message sent to either a single destination or the whole group will be marked with this address (in the source field). As soon as the local address is know, a SET_LOCAL_ADDRESS event will be sent up the stack, followed by a START_OK.
When a STOP event is received, the sockets are closed and a STOP_OK event is passed up the stack as acknowledgment. When a channel is closed, local address becomes meaningless (since based on a open socket).
Messages sent down the stack will be added a UDP header containing the group name and then put on the network as datagram packets. Datagrams received from the network will be converted into messages and their UDP header removed. If the header's group name is different from the channel's group name, then the message will be dropped. Otherwise, it is passed up the stack.
UDP can either use IP multicasting or unicasting to disseminate messages to the group. If option ip_mcast is false, unicast is used: when a message is to be sent to all group members, it is sent n times to each member. To do this, UDP has to cache the membership when receiving VIEW_CHANGE events.
The IP multicast address and port can be configured using options mcast_addr and mcast_port. Although it is not a problem when different groups use the same IP multicast address and port (since messages by members belonging to a different group are discarded by UDP), it is often preferable to choose different parameters. However, all group members must have their UDP layers configured too the same IP multicast address and port (when using IP mcast).
url:http://www.cs.cornell.edu/Info/Projects/JavaGroupsNew/userguide/html/user/index.html
这里使用默认的cache.event.listeners=com.opensymphony.oscache.plugins.clustersupport.JavaGroupsBroadcastingListener
oscache集群的默认配置如下:
UDP(mcast_addr=231.12.21.132;mcast_port=45566;ip_ttl=32;\
mcast_send_buf_size=150000;mcast_recv_buf_size=80000):\
PING(timeout=2000;num_initial_members=3):\
MERGE2(min_interval=5000;max_interval=10000):\
FD_SOCK:VERIFY_SUSPECT(timeout=1500):\
pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800;max_xmit_size=8192):\
UNICAST(timeout=300,600,1200,2400):\
pbcast.STABLE(desired_avg_gossip=20000):\
FRAG(frag_size=8096;down_thread=false;up_thread=false):\
pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=true)
FD
The failure detection layer (FD) periodically tries to reach its nearest neighbor to the right
Figure 7.1: Failure detection layer
The nearest neighbor is always computed based on the local view. Since all views in all stacks have the same member ordering, every member can always determine its next neighbor to the right. When a new view is received, the neighbor is recomputed.
The FD layer periodically pings its neighbor. When no response has been received after max_tries (each with a timeout), a SUSPECT message is multicast to all members of the group. The GMS layer which is currently the coordinator processes the message, all others ignore it7.1. In the example, the coordinator would be A. It pings B which in turn pings C. The last member ( E) 'wraps around' and pings the first (A).
FRAG(the fragmentation protocol layer)
It essentially breaks up bigger messages into smaller ones and reassembles them at the receiver's side.
GMS
The group membership service is probably the most important protocol layer, and also the most complex to implement. The description is based on the current (March 99) GMS layer, but work is underway to replace this layer with a new one (RpcGMS).
When a CONNECT event is received by the GMS layer, it tries to join the group. To do so, it first tries to retrieve the initial membership. If no other members can be found, it assumes it is the first member and sends a VIEW_CHANGE event up/down the stack. Otherwise, it determines the coordinator and sends a unicast message to the latter to join it to the group. The coordinator adds the new member to its local view and multicasts the new view to all GMS layers, which then in turn generate VIEW_CHANGE events up/down the stack.
When a member wants to leave a group, it disconnects from the channel. This causes a DISCONNECT event to be sent down where it is caught by the GMS layer. The latter sends a unicast LEAVE request to the coordinator, which in turn removes the member from its local view and multicasts the new view.
When a SUSPECT event is received by the GMS layer, if the layer is the current coordinator, the member will be removed from the local view and a new view multicast to all members. Otherwise, the event is just dropped. In case the suspected member is the coordinator itself, the next member of the group in order takes over and multicasts a new view (excluding the old coordinator).
PING
The PING layer is responsible for finding the initial membership of a group. It does so upon reception of a FIND_INITIAL_MBRS event (sent by the GMS layer). When done, a FIN_INITIAL_MBRS_OK event is sent up the stack, containing the members found as argument. GMS waits until it receives the initial membership, and - based on it - determines the current coordinator to which it then sends a join request. When not receiving the initial members within a certain time frame, a timeout is received, and the GMS creates a singleton group (with itself as only member).
Currently the initial membership is found either using a multicast to an IP multicast address to which all members respond, or using the Router daemon (see 3.8.1), if IP multicast is not enabled.
UDP
UDP is currently the bottommost layer available to use in a protocol stack.
When it receives a START event (upon channel connection), it creates a unicast and an IP multicast socket. The IP address plus the port number of the unicast socket form the channel's address: every message sent to either a single destination or the whole group will be marked with this address (in the source field). As soon as the local address is know, a SET_LOCAL_ADDRESS event will be sent up the stack, followed by a START_OK.
When a STOP event is received, the sockets are closed and a STOP_OK event is passed up the stack as acknowledgment. When a channel is closed, local address becomes meaningless (since based on a open socket).
Messages sent down the stack will be added a UDP header containing the group name and then put on the network as datagram packets. Datagrams received from the network will be converted into messages and their UDP header removed. If the header's group name is different from the channel's group name, then the message will be dropped. Otherwise, it is passed up the stack.
UDP can either use IP multicasting or unicasting to disseminate messages to the group. If option ip_mcast is false, unicast is used: when a message is to be sent to all group members, it is sent n times to each member. To do this, UDP has to cache the membership when receiving VIEW_CHANGE events.
The IP multicast address and port can be configured using options mcast_addr and mcast_port. Although it is not a problem when different groups use the same IP multicast address and port (since messages by members belonging to a different group are discarded by UDP), it is often preferable to choose different parameters. However, all group members must have their UDP layers configured too the same IP multicast address and port (when using IP mcast).
发表评论
-
Java并发编程:volatile关键字解析
2015-07-30 11:30 594转:http://www.cnblogs.com/dolp ... -
Java内存模型
2015-07-29 13:55 8781. 概述 多任务和 ... -
自定义classloader
2015-07-29 13:54 641转:http://tiantian911.iteye.com ... -
自定义ClassLoader实现java应用核心逻辑模块热部署
2015-07-29 13:51 966转:http://blog.csdn.net/zhangda ... -
java classloader原理初探
2015-07-29 10:14 629转:http://www.cnblogs.com/ ... -
Java 内存分配全面浅析
2015-07-29 08:52 575转:http://blog.csdn.net/shimi ... -
http stream
2014-07-29 16:38 1076StringBuilder sb = new String ... -
Tomcat远程调试
2011-04-09 12:33 1037需要在Tomcat中的catalina.bat中添加如下的一行 ... -
用jmx监控多台服务器(tomcat)
2010-09-08 18:25 4536因为需要写一个后台监控服务器的程序,涉及到jmx,也涉 ... -
call cmd /c start 一点疑问
2010-09-01 10:16 2215call "cmd /c start aaa.bat ... -
Windows计划任务之schtasks
2010-08-30 13:21 3546创建:SCHTASKS /Create /RU SYSTEM ... -
ajax返回值中有中文存在的乱码现象
2010-08-27 16:28 1411ajax返回值中有中文存在的乱码现象,解决就加入下面一行代码即 ... -
MIME TYPE
2010-08-26 16:23 7216最近要做需要在页面上放音频的东西,因此需要用到mime typ ... -
JMX问题
2010-08-20 17:20 5464这个问题貌似是启动tomcat之后就获取不到jmx的链接了,不 ... -
Eclipse控制台乱码
2010-08-05 15:18 4855安装了Eclipse,在运行tomcat时,控制台的中文显示乱 ... -
JMX服务端和客户端的代码
2010-07-27 15:37 3519服务端代码如下 package com.rmi; i ... -
JMX连接Tomcat的JMX测试类
2010-07-27 15:33 3264首先是为了使tomcat支持JMX,必须在tomcat的启动项 ... -
JMX的一个链接类
2010-07-27 09:37 1429package com.pachira.oamp.jmxS ... -
java中文转unicode码
2010-07-22 11:04 43322转载地址:http://www.iteye.com/topic ... -
获取POST数据的值
2010-07-21 14:17 9870当method为POST,Content-Type为 ...
相关推荐
本文叙述了如何使用oscanche,最后的配置需要在oscache.properties中完成
OSCache由OpenSymphony设计,它是一种开创性的JSP定制标记应用,提供了在现有JSP页面之内实现快速内存缓冲的功能。OSCache是一个广泛采用的高性能的J2EE缓存框架,OSCache能用于任何Java应用...支持集群,集群缓存数
OScache配置 缓存技术 一、缓存整个页面 在 OSCache组件中提供了一个CacheFilter用于实现页面级的缓存,主要用于对web应用中的某些动态页面进行缓存,尤其是那些需要生成PDF 格式文件/报表、图片文件等的页面,...
二级缓存插件OScache配置,很好的学习资料
NULL 博文链接:https://zhenghuazhi.iteye.com/blog/1135620
NULL 博文链接:https://yanxiansheng.iteye.com/blog/1636690
最全的配置文件资料,springMvc包含josn、xml、文件下载、静态资源配置、日志拦截器、freeMarker、错误日志、国际化等各种配置
springmvc最全的配置文件资料,springMVC包含json、xml、文件下载、静态资源配置、日志拦截器、freeMarker、错误日志、国际化等各种配置
oscache的简单介绍
OSCache标记库由... (4) 支持集群:集群缓存数据能被单个的进行参数配置,不需要修改代码。 (5) 缓存过期:你可以有最大限度的控制缓存对象的过期,包括可插入式的刷新策略(如果默认性能不能满足需要时)。
OSCache标记库由OpenSymphony设计,... 支持集群--集群缓存数据能被单个的进行参数配置,不需要修改代码。 缓存记录的过期--你可以有最大限度的控制缓存对象的过期,包括可插入式的刷新策略(如果默认性能不需要时)。
oscache-2.1.jar oscache-2.1.jar
javaweb做页面缓存常用,OSCache是一个工业级的J2EE缓存实现。OSCache不但能缓存java对象,还可以缓存页面,http请求和二进制内容,例如pdf文件等。通过应用OSCache,我们不但可以实现通常的Cache功能,还能够改善...
OSCache是当前运用最广的缓存方案, Hibernate,jsp,页面等都对其有支持,下面简单介绍一下OSCache的配置和使用过程
OSCACHE配置,文档,示例,JAR包,非常齐全
oscache缓存技术入门实例
1、OSCache是什么? 2、OSCache的特点 3、有关“用OSCache进行缓存对象”的研究
OSCache学习例子 实例 很好的与j2ee结合
使用oscache进行缓存,大大提高web系统运行效率
Cache是一种用于提高系统响应速度、改善系统运行性能的技术。尤其是在Web应用中,通过缓存页面的...OSCache是个一个被广泛采用的高性能的J2EE缓存框架,OSCache还能应用于任何Java应用程序的普通的缓存解决方案。。。。