[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Messages posted by: raven  XML
Profile for raven -> Messages posted by raven [2]
Author Message
Dear all,

I'm learning ehcache library recently and embedded it with some testing java codes. In my testing network environment, I only can use unicast instead of multicast. Hence, I used and configured the ManualRMICacheManagerPeerProvider. The replication of ehcache worked fine for all caches.

I have conducted some further testing of ehcache on its stability by plugging out the connection cable between two replicated servers. The data would remain synchronized after I put back the cable.

However, I noticed one difficulty of ehcache when the connection was lost between two servers before I start my testing program in one of the servers. In this scenario, my testing program would take very long time to start up. Through tracing logs, I found each cache would cost around 19 to 25 seconds to detect RemoteException when tried to bootstrap.

I have reviews the source code of ehcache, under the manual mode, ehcache didn't follow the formula MulticastKeepaliveHeartbeatSender.getHeartBeatInterval() * 2 + SHORT_DELAY like what multicast does to wait cache to join cluster. Instead, Its getTimeForClusterToForm() time is 0. When the manual mode tried to listRemoteCachePeers() during bootstrap, it actually called lookupRemoteCachePeer() to look up RMI URLs one by one. Thus, in order to speed up the timeout of bootstrap, I have followed Oracle's document to reduce sun.rmi.transport.tcp.handshakeTimeout (Default is 15 seconds) and sun.rmi.transport.tcp.handshakeTimeout (Default is 1 minutes) two system properties. What a pity, it didn't work and affect at all to echache behavior.

I'd like to ask any expert here, is there any other solution to achieve better timeout timing in my scenario ? Thank you for your time and reading ! Cheers !
Based on all well documented articles in Quartz's website, I found out they only mention that TriggerListener and JobListener can be configured as general listeners in properties file while SchedulerListener should be added during run time after the scheduler instance is started.

I have tried to configure customized SchedulerListener inside properties file which followed the same way of TriggerListener and JobListener configurations. However, after the scheduler started, the result of getSchedulerListeners().size() method return me 0. It proved that the customized SchedulerListener was not successfully added.

Hence, my query is: Is there any way to configure customized SchedulerListener inside properties file so that it will be added during QuartzInitializerListener triggered ?
 
Profile for raven -> Messages posted by raven [2]
Go to:   
Powered by JForum 2.1.7 © JForum Team