[JBoss Messaging] - Re: Messaging 1.3 Clustering question
by nbakizada
Ok. That makes sense in terms of the local consumption. There are a couple more oddities in running clustered messaging (I'm on 1.4 now).
I'm having trouble understanding if the 2 nodes in a cluster act as some sort of primary/secondary, or if they're both equal primaries. In the event of a basic failover (one of the 2 appservers goes down), things failover to the other just fine. But what happens if, say, both servers are running, but are somehow unable to connect to each over the network (so each thinks the other is unavailable). What happens to the messages stored in the shared database?
Under normal circumstances, when node A held, let's say, 100 messages, and node A went down. The 100 messages would "appear" on Node B after failover was complete (being read from the shared database).
What happens in the scenario where both servers stay up, but can't see each other on the network?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120685#4120685
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120685
18 years, 5 months
[JBossCache] - CacheLoaderInterceptor behavior
by nnnnn
We're using a custom CacheLoader in a somewhat non-standard way. Our CacheLoader is read-only, and it's designed to get a node from a different server if not on the current server (the difference between it and the TcpDelegatingCacheLoader is that this cacheloader figures out where to go and get it).
What the CacheLoaderInterceptor is doing that we don't want it to do is that when we put an object into a cache and that node doesn't exist in the local cache, it goes to CacheLoader to get that node before proceeding with the put. I understand the thought process behind this - if the CacheLoader is being used as a backing store, then you want to get the node back into memory before adding another key/value pair. However, we're not using it this way. I won't get into the details on why, but what we'd like is to have the CacheLoader "get" only be invoked on an explicit "get", and never on a "put".
Functionally, this won't make a difference, but there will be a performance difference.
Any suggestions on how this can be accomplished?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120669#4120669
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120669
18 years, 5 months
[Security & JAAS/JBoss] - RMI & JBOSS
by markbabcock
I'm running the bungled version of jboss-portal-2.6.3. I have a class within my war file that makes an RMI call to an external app. I have tried using the command line args to run in java2 security. However, I'm still getting a security error. I'm running the bundled version of jboss with the portal. Any ideas?
run -Djava.security.manager -Djava.security.policy=server.policy
java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:9001 connect,resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1034)
at java.net.Socket.connect(Socket.java:513)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.(Socket.java:366)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120667#4120667
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120667
18 years, 5 months