JGroups

We use hibernate-search for fulltext indexing of our entities in wildfly 8.2 (using the hibernate/hibernate-search and infinspan libraries inlcuded with wildfly 8.2). Running as standalone node or in a domain with a dedicated hibernate search master and the org.hibernate.search.store.impl.FSDirectoryProvider this has been working fine for several years (and jboss versions). We would now like to deploy this system to a HA clustered environment with wildfly 8.2 running behind a load balancing proxy. We want to have a dynamically scalable cluster without a point of failure in the sense of a

I have a website running with JBoss 4.2.2 on an existing Red Hat server. I'm setting up a second server so as to have a clustered pair (which will then be load-balanced). However, I can't get them to cluster successfully. The existing server starts up JBoss with: run.sh -c default -b 0.0.0.0 (I know the 'default' configuration doesn't support clustering out of the box - I'm using a modified version of it which includes clustering support.) When I start the second JBoss instance with the same command, it forms its own cluster without noticing the first. Both use the same partition name and

I have seen the question: Communication between two separate Java desktop applications (answer: JGroups) and I'm thinking about implementing something with JavaGroups or straight RMI but speed is of the essence. I'm not sending large amounts of data around (content of MIDI Messages, so 3 bytes each, no more than say two messages every three milliseconds) and this will be all on the same machine. Is it daft to think that RMI/JGroups on the same physical machine will be slow? (My thought is that I can't afford more than 1ms of latency, since I've already got some, but I'm not sure how to best

不少人看到 J2Cache 第一眼时，会认为这就是一个普普通通的缓存框架，和例如 Ehcache、Caffeine 、Spring Cache 之类的项目没什么区别，无非是造了一个新的轮子而已。事实上完全不是一回事！ 目前缓存的解决方案一般有两种： 内存缓存（如 Ehcache） —— 速度快，进程内可用 集中式缓存（如 Redis）—— 可同时为多节点提供服务 现有的缓存框架已经非常成熟而且优秀，J2Cache 无心造一个新的轮子，它要解决的几个问题如下： 使用内存缓存时，一旦应用重启后，由于缓存数据丢失，缓存雪崩，给数据库造成巨大压力，导致应用堵塞 使用内存缓存时，多个应用节点无法共享缓存数据 使用集中式缓存，由于大量的数据通过缓存获取，导致缓存服务的数据吞吐量太大，带宽跑满。现象就是 Redis 服务负载不高，但是由于机器网卡带宽跑满，导致数据读取非常慢 在遭遇问题1、2 时，很多人自然而然会想到使用 Redis 来缓存数据，因此就难以避免的导致了问题3的发生。 当发生问题 3 时，又有很多人想到 Redis 的集群，通过集群来降低缓存服务的压力，特别是带宽压力。 但其实，这个时候的 Redis 上的数据量并不一定大，仅仅是数据的吞吐量大而已。 咱们假设这样一个场景： 有这么一个网站，某个页面每天的访问量是 1000万，每个页面从缓存读取的数据是 50K。缓存数据存放在一个

I'm working on Wildfly 9 with Infinispan 7.2.3. I'm facing up to a strange problem related to distributed cache: On the application server i have N deployed wars exposing REST services Each service code has the common duty to check if a CacheManager si already present on JNDI, if yes, it uses it otherwise i creates a new one and the bind it to the JNDI. So every war works with a unique CacheManager instance. The Infinispan CacheManager is configured in distributed mode. The infinispan and jgroups are provided from the application server. After a re-deploy operation (undploy and deploy) of all

群组通信使用“组和成员”的概念。一般来说，成员是组的一个部分，一个组中包括多个成员。或者可以理解为，成员是一个节点，一组是一个集群。 一个节点是一个进程，位于某个主机上。一个集群可以有一个或多个节点。在同一台主机上可以有多个节点，所有节点可能会分属不同的集群。当然节点也可以运行在不同的主机上。 JGroups是一个可靠的组通信工具包 。 节点进程可以加入到一个组，发送消息给组内的所有成员或单个成员，接收组中任何成员发送的消息。 JGroups会跟踪组中的每一个成员，当新成员加入、已有成员退出、已有成员异常时，会发送通知消息给组成员。 一个组使用名字来标识它自己。 组没必要显式地创建，当一个节点进程加入一个不存在的组，该组就被自动创建。 一个群组可以位于同一台主机上、可以位于同一个局域网内、或通过广域网。 如上为 JGroups 的架构图，它包括三个部分： 通道，为应用层提供构建可靠群组通信的机制。 构建块，位于通道之上，是对通道进行了一个更高层面的抽象和封装，预留了更多的程序弹性，用法上也更复杂。 协议栈，实现一组指定的协议，被通道使用。 一个通道需要连接到一个协议栈，每当应用程序发送消息，通道传递给它的协议栈，并将它传递给最顶层的协议。该协议处理该消息将其传递给下层协议，因此消息被处理从一个协议到下一个协议直到最底层的协议，最底层的协议（传输层协议）将消息发送到网络上面