[JBossCache] - JBoss Cache with Weblogic 9.2 Cluster
by gerinjacob
Hi all,
I am facing problem with JBoss caching when used in Weblogic 9.2 clustered environment.
I have created a cluster in Weblogic Server, under which I have 2 managed servers. The setup is done in a single machine.
I congifured JBoss xml for caching and deployed my application.
But I am getting the following error.
<weblogic.cluster.MessageReceiver> <<WLS Kernel>> <> <> <1198306689420> <BEA-000110> <Multicast socket receive error: java.io.StreamCorruptedException
java.io.StreamCorruptedException
at java.io.ObjectInputStream$BlockDataInputStream.readBlockHeader(ObjectInputStream.java:2410)
at java.io.ObjectInputStream$BlockDataInputStream.refill(ObjectInputStream.java:2443)
at java.io.ObjectInputStream$BlockDataInputStream.read(ObjectInputStream.java:2515)
at java.io.DataInputStream.readInt(DataInputStream.java:353)
at java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:2720)
at java.io.ObjectInputStream.readInt(ObjectInputStream.java:930)
at weblogic.cluster.MulticastManager.run(MulticastManager.java:408)
at java.lang.Thread.run(Thread.java:595)
Find below the configuration I did for JBoss Caching:
<?xml version="1.0" encoding="UTF-8"?>
|
| <server>
| <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
| <!-- ==================================================================== -->
| <!-- Defines TreeCache configuration -->
| <!-- ==================================================================== -->
| <mbean code="org.jboss.cache.TreeCache"
| name="jboss.cache:service=TreeCache">
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
| <!-- Configure the TransactionManager -->
| <attribute name="TransactionManagerLookupClass">org.jboss.cache.BatchModeTransactionManagerLookup</attribute>
| <!--
| Node locking level : SERIALIZABLE
| REPEATABLE_READ (default)
| READ_COMMITTED
| READ_UNCOMMITTED
| NONE
| -->
| <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
| <!--
| Valid modes are LOCAL
| REPL_ASYNC
| REPL_SYNC
| INVALIDATION_ASYNC
| INVALIDATION_SYNC
| -->
| <attribute name="CacheMode">REPL_ASYNC</attribute>
| <!-- Name of cluster. Needs to be the same for all clusters, in order
| to find each other
| -->
| <attribute name="ClusterName">eOrder_Cls</attribute>
| <!-- JGroups protocol stack properties. Can also be a URL,
| e.g. file:/home/bela/default.xml
| <attribute name="ClusterProperties"></attribute>
| -->
| <attribute name="ClusterConfig">
| <config>
| <!-- UDP: if you have a multihomed machine,
| set the bind_addr attribute to the appropriate NIC IP address -->
| <!-- UDP: On Windows machines, because of the media sense feature
| being broken with multicast (even after disabling media sense)
| set the loopback attribute to true -->
| <UDP mcast_addr="228.1.2.3" mcast_port="48866"
| ip_ttl="64" ip_mcast="true"
| mcast_send_buf_size="80000" mcast_recv_buf_size="80000"
| ucast_send_buf_size="80000" ucast_recv_buf_size="80000"
| loopback="true"/>
| <PING timeout="2000" num_initial_members="3"
| up_thread="false" down_thread="false"/>
| <MERGE2 min_interval="10000" max_interval="20000"/>
| <FD shun="true" up_thread="true" down_thread="true"/>
| <VERIFY_SUSPECT timeout="1500"
| up_thread="false" down_thread="false"/>
| <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
| max_xmit_size="8192" up_thread="false" down_thread="false"/>
| <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
| down_thread="false"/>
| <pbcast.STABLE desired_avg_gossip="20000"
| up_thread="false" down_thread="false"/>
| <FRAG frag_size="8192"
| down_thread="false" up_thread="false"/>
| <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
| shun="true" print_local_addr="true"/>
| <pbcast.STATE_TRANSFER up_thread="false" down_thread="false"/>
| </config>
| </attribute>
| <!--
| The max amount of time (in milliseconds) we wait until the
| initial state (ie. the contents of the cache) are retrieved from
| existing members in a clustered environment
| -->
| <attribute name="InitialStateRetrievalTimeout">20000</attribute>
| <!--
| Number of milliseconds to wait until all responses for a
| synchronous call have been received.
| -->
| <attribute name="SyncReplTimeout">20000</attribute>
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <attribute name="LockAcquisitionTimeout">15000</attribute>
| <!-- Name of the eviction policy class. -->
| <attribute name="EvictionPolicyClass"></attribute>
| <!--
| <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
| -->
| <!-- Specific eviction policy configurations. This is LRU -->
| <attribute name="EvictionPolicyConfig">
| <config>
| <attribute name="wakeUpIntervalSeconds">5</attribute>
| <!-- Cache wide default -->
| <region name="/_default_">
| <attribute name="maxNodes">5000</attribute>
| <attribute name="timeToLiveSeconds">1000</attribute>
| </region>
| <region name="/org/jboss/data">
| <attribute name="maxNodes">5000</attribute>
| <attribute name="timeToLiveSeconds">1000</attribute>
| </region>
| <region name="/org/jboss/test/data">
| <attribute name="maxNodes">5</attribute>
| <attribute name="timeToLiveSeconds">4</attribute>
| </region>
| </config>
| </attribute>
| <!--
| Indicate whether to use region based marshalling or not. Set this to true if you are running under a scoped
| class loader, e.g., inside an application server. Default is "false".
| -->
| <attribute name="UseRegionBasedMarshalling">false</attribute>
| </mbean>
| </server>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115155#4115155
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115155
18 years, 3 months
[JBoss Messaging] - Re: Clustered Connection Factories
by paduffy
Similar question. My application structure is as follows:
- Several dozen clients issue requests into a well know Q in AS instance CENTRAL (basically a message router).
- MDB in CENTRAL performs routing based on message properties. Request is then placed on topic maintained in AS instance CENTRAL.
- Several hundred (geo distributed) AS instance EDGE each have MDB listening to the remote topic maintained in CENTRAL. They decide to accept a messsage via the selector they apply to the remote topic.
The idea is that internal messaging in EDGE must continue to function when CENTRAL is down. Thus the broker in CENTRAL performing the routing function, and the independent brokers in each EDGE.
So my question is what is the recommended strategy to acheive HA at instance CENTRAL (the routing function). We were considering a clustered pair of CENTRAL. Clients connecting to CENTRAL would use a clustered connection to submit requests into the system. But what about the MDBs listening in EDGE?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115144#4115144
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115144
18 years, 4 months
[Security & JAAS/JBoss] - Re: Custom principal in Web application
by brent.atkinson
I think I have found where the caller principal is being populated: org.jboss.security.plugins.JaasSecurityManager.updateCache(...). It appears what occurs is that once a user authenticates, a DomainInfo object is created and stored in the login domain's cache. The DomainInfo object is assigned the Subject for the authenticated user which is a copy of the Subject created by the authentication process.
The caller Principal is then manually assigned to the DomainInfo object by searching the original Subject for a Group called "CallerPrincipal" and if found taking the first Principal object in the Group. If no such Group is found and the Principal can't be reused from the cache, the first non-Group Principle found in the Subject's set of Principals is assigned to the DomainInfo object.
It seems (with the code from 4.0.5 GA at least), that unless you add the CallerPrincipal Group in your module(s), it doesn't matter if you specify the custom class in your login config... despite using instances of your Principal class in the login modules, the code that calls the JaasSecurityManager.isValid() authentication code from the web container passes in an instance of SimplePrincipal org.jboss.web.tomcat.security.JBossSecurityMgrRealm(line 491). At JaasSecurityManager.updateCache() (line 778) the manager has a non-null principal so the test fails and the subject is not scanned for the principal as previously described (if it did it would yield the custom principal), instead, it uses the SimplePrincipal passed in from the web container.
So, to make a long story short... make sure you include a Group named "CustomPrincipal" with the custom principal added to it. Otherwise, you'll always get the SimplePrincipal passed in from the tomcat side.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115135#4115135
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115135
18 years, 4 months