[cas-dev] JBoss Cache Ticket Registry in clustered enviroment addTicket() RuntimeException "failure to marshal argument(s)"

Scott Battaglia scott.battaglia at gmail.com
Wed Oct 3 23:53:07 EDT 2007


Lee,

Do you have the stack trace?  Can you post the LoginTicket code (or email it
to me privately) so we can see how it compares to the existing Tickets.

On a different note, why do you guys need to add tickets from the Web flow.
Generally they are only created at the service level.

-Scott

On 10/3/07, Lee Braddock <lee.braddock at ccci.org> wrote:
>
>  Scott and CAS Development Team,
>
>
>
> We are using org.jasig.cas.ticket.registry.JBossCacheTicketRegistry in a
> clustered environment.  The underlying tree cache is from
> JBossCache-1.4.1.SP3.  Our jbossCache.xml is listed below (which is
> virtually identical to the cas server release provided sample).
>
>
>
> We are having no problems running cas-server.3.0.7 out of the box with
> this configuration.
>
>
>
> However, during Spring Framework based cas login web flow, when we attempt
> to add our own login ticket (a class or our own making which extends
> org.jasig.cas.ticket.AbstractTicket and implements
> org.jasig.cas.ticket.TicketGrantingTicket in like manner to
> org.jasig.cas.ticket.TicketGrantingTicketImpl) to the jboss cache (as in
> org.jasig.cas.ticket.registry.JBossCacheTicketRegistry.addTicket(loginTicket)),
> the method throws the java.lang.RuntimeException: "failure to marshal
> argument(s)".
>
>
>
> In addition, if we remove from the jboss cache ticket registry (as in
> org.jasig.cas.ticket.registry.JBossCacheTicketRegistry.deleteTicket(ticketGrantingTicketId))
> an already successfully added ticket granting ticket (as in
> org.jasig.cas.CentralAuthenticationService.createTicketGrantingTicket(credentials)),
> and then attempt to add it back (as in
> org.jasig.cas.ticket.registry.JBossCacheTicketRegistry.addTicket(ticketGrantingTicket)),
> we get the same exception.
>
>
>
> Note that this exception is thrown regardless of whether or not the
> jbossCache.xml UseMarshalling attribute is set to true of false.
>
>
>
> What is the explanation for this and how can we achieve adding
> org.jasig.cas.ticket based classes of our own making to the jboss cache
> ticket registry?
>
>
>
> Thanks very much.
>
>
>
> Lee
>
>
>
>
>
>
>
> jbossCache.xml:
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
>
>
>
> <!-- =====================================================================
> -->
>
> <!--
> -->
>
> <!--  Sample TreeCache Service Configuration
>                  -->
>
> <!--
> -->
>
> <!-- =====================================================================
> -->
>
>
>
> <server>
>
>
>
>     <!--
> ==================================================================== -->
>
>     <!-- 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.DummyTransactionManagerLookup</attribute>
>
>
>
>         <!--
>
>             Isolation 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_SYNC</attribute>
>
>
>
>         <!--
>
>         Just used for async repl: use a replication queue
>
>         -->
>
>         <attribute name="UseReplQueue">false</attribute>
>
>
>
>         <!--
>
>             Replication interval for replication queue (in ms)
>
>         -->
>
>         <attribute name="ReplQueueInterval">0</attribute>
>
>
>
>         <!--
>
>             Max number of elements which trigger replication
>
>         -->
>
>         <attribute name="ReplQueueMaxElements">0</attribute>
>
>
>
>         <!-- Name of cluster. Needs to be the same for all clusters, in
> order
>
>              to find each other
>
>         -->
>
>         <attribute name="ClusterName">TreeCache-Cluster</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, e.g bind_addr="192.168.0.2"
>
>                 -->
>
>                 <!-- 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.0.0.1" mcast_port="45566"
>
>                     ip_ttl="64" ip_mcast="true"
>
>                     mcast_send_buf_size="150000"
> mcast_recv_buf_size="80000"
>
>                     ucast_send_buf_size="150000"
> ucast_recv_buf_size="80000"
>
>                     loopback="false"/>
>
>                 <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" />
>
>                                                                     <!--
> <FD_SOCK/> -->
>
>                 <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="true"
> down_thread="true"/>
>
>             </config>
>
>         </attribute>
>
>
>
>
>
>         <!--
>
>          Whether or not to fetch state on joining a cluster
>
>          NOTE this used to be called FetchStateOnStartup and has been
> renamed to be more descriptive.
>
>         -->
>
>         <attribute name="FetchInMemoryState">true</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">15000</attribute>
>
>
>
>         <!--
>
>             Number of milliseconds to wait until all responses for a
>
>             synchronous call have been received.
>
>         -->
>
>         <attribute name="SyncReplTimeout">15000</attribute>
>
>
>
>         <!-- Max number of milliseconds to wait for a lock acquisition -->
>
>         <attribute name="LockAcquisitionTimeout">10000</attribute>
>
>
>
>         <!-- Name of the eviction policy class. -->
>
>         <attribute name="EvictionPolicyClass"></attribute>
>
>
>
>        <!--
>
>           Indicate whether to use 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="UseMarshalling">true</attribute>
>
>
>
>                            <attribute
> name="StateTransferVersion">130</attribute>
>
>
>
>         <!--attribute name="CacheLoaderConfiguration">
>
>             <config>
>
>                 <passivation>false</passivation>
>
>                 <preload>/</preload>
>
>                 <shared>false</shared>
>
>
>
>                 <cacheloader>
>
>                     <class>org.jboss.cache.loader.ClusteredCacheLoader
> </class>
>
>                     <properties>
>
>                         timeout=1000
>
>                     </properties>
>
>                     <async>false</async>
>
>                     <fetchPersistentState>false</fetchPersistentState>
>
>                     <ignoreModifications>false</ignoreModifications>
>
>                 </cacheloader>
>
>             </config>
>
>         </attribute-->
>
>     </mbean>
>
> </server>
>
>
>
> *Lee Braddock*
>
> *Sr. Applications Developer*
>
> *Enterprise** Framework*
>
> *ITG Applications *
>
> *Campus Crusade for Christ*
>
> *407-826-2166 office*
>
> http://itg.ccci.org
>
>
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>


-- 
-Scott Battaglia

LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20071003/f938a78a/attachment-0001.html 


More information about the cas-dev mailing list