Cluster with JBossCacheTicketRegistry
Barrow Kwan
bhkwan at thoughtworks.com
Tue Aug 7 21:04:07 EDT 2007
Hi Arnaud,
My configuration is similar to what you mentioned ( except the IP
address different ) .. I can see "GMS: address 10.2.1.61:7800" on
one machine and "GMS:address 10.2.1.60:7800" on another machine. I
also turned on jgroups debug log and I can see the two machines are
communicating..
eg the log on 10.2.1.60:
2007-08-07 19:56:49,999 DEBUG [org.jgroups.protocols.FD] - <received
ack from 10.2.1.61:7810>
2007-08-07 19:56:50,259 DEBUG [org.jgroups.protocols.MERGE2] -
<initial_mbrs=[[own_addr=10.2.1.61:7810, coord_addr=10.2.1.60:7810,
is_server=true], [own_addr=10.2.1.60:7810, coord_addr=10.2.1.60:7810,
is_server=true]]>
2007-08-07 19:56:52,461 DEBUG [org.jgroups.util.TimeScheduler] -
<Running task true>
But I don't think they have exchanged any authentication data.
I have created two different tesitng hosts ( using casphp ) with
test.php
On Host A, test.php will point to CAS Server A ( 10.2.1.60 ).
On Host B, test.php will point to CAS Server B ( 10.2.1.61 ).
On Machine XYZ, ( my local desktop ), I open my browser and access
Host A test.php, it direct me to the CAS Server A (10.2.1.60 )'s
login screen. I login fine. Now on the same browser, I access Host
B's test.php. It direct me to the CAS Server B's (10.2.1.61 ) login
screen. My assumption is if I go to Host B's test.php, it should
authenticate me without login again. On the other hand, it is
telling me that the JBoss cluster stuff isn't working.
Thanks
On Aug 7, 2007, at 5:51 AM, Arnaud Lesueur wrote:
> Barrow,
>
> I guess that if you see "GMS: address is 10.1.1.1:7800" on both
> instance there is a configuration issue.
>
> My config example should be adapted :
> - on the first host put :
> <TCP bind_addr=" 10.1.1.1" start_port="7800" loopback="true"/>
> <TCPPING initial_hosts="10.1.1.2[7800]" ...
> - on the seconde host put :
> <TCP bind_addr="10.1.1.2" start_port="7800" loopback="true"/>
> <TCPPING initial_hosts="10.1.1.1[7800]" ...
>
> You should also turns on log on JGroups in order to have more
> informations.
>
>
> Regards,
>
>
> Arnaud Lesueur
>
>
> On 8/6/07, Barrow Kwan <bhkwan at thoughtworks.com> wrote:
> Hi Arnaud,
> I finally get a chance to setup JBossCacheTicketRegistry for CAS
> clustering. I think I have this setup correctly ( as least I
> didnt' see any error and I can see
>
> "GMS: address is 10.1.1.1:7800"
>
> on the two cluster server's log.
>
> However, I didn't seem to see the ticket being replicate between
> the CAS instance?
>
>
>
> Barrow
>
>
> On May 8, 2007, at 9:14 AM, Arnaud Lesueur wrote:
>
>> On 5/8/07, Barrow Kwan <bhkwan at thoughtworks.com> wrote:
>> Can anyone provide an example to use JBossCacheTicketRegistry? is
>> there any implementation that is not using multicast? ( eg
>> Berkeley DB or JDBC etc... )
>>
>> thanks
>>
>> Hi,
>>
>> You should have a look in the directory : cas-server-integration-
>> jboss\src\test\resources. There are 2 files :
>> - jbossTestContext.xml : contains the bean definition that you
>> should modify in applicationcontext.xml
>> - jbossTestCache.xml : add it in your classpath
>>
>> BTW, these configuration examples are using mulcasting over UDP.
>> But, JBossCache is using JGroups for the replication process and
>> messages.
>>
>> Here is an example of configuration over TCP :
>> <config>
>> <TCP bind_addr="10.155.18.126" start_port="7800"
>> loopback="true"/>
>> <TCPPING initial_hosts="10.155.18.127[7800], 10.155.18.128
>> [7800],10.155.18.129[7800]"
>> port_range="3"
>> timeout="3500"
>> num_initial_members="3"
>> up_thread="true"
>> down_thread="true"/>
>> <MERGE2 min_interval="5000" max_interval="10000"/>
>> <FD shun="true" timeout="2500" max_tries="5" up_thread="true"
>> down_thread="true" />
>> <VERIFY_SUSPECT timeout="1500" down_thread="false"
>> up_thread="false" />
>> <pbcast.NAKACK down_thread="true" up_thread="true"
>> gc_lag="100" retransmit_timeout="300,600,1200,2400,4800,9600" />
>> <pbcast.STABLE desired_avg_gossip="20000" down_thread="false"
>> up_thread="false" stability_delay="1500"/>
>> <pbcast.GMS join_timeout="5000"
>> join_retry_timeout="2000"
>> shun="true"
>> print_local_addr="true"
>> down_thread="true"
>> up_thread="true"/>
>> <pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
>> </config>
>>
>> More information is available on JBoss Website : http://
>> docs.jboss.com/jbossas/guides/clusteringguide/r2/en/html_single/
>> #jbosscache.chapt
>>
>> And as you said, there is also other implementation that are not
>> using multicast such ad BerkeleyDB and JDBC.
>>
>> Regards,
>>
>> --
>> Arnaud Lesueur
>> _______________________________________________
>> Yale CAS mailing list
>> cas at tp.its.yale.edu
>> http://tp.its.yale.edu/mailman/listinfo/cas
>
> Barrow Kwan
> ThoughtWorks Inc
> 410 Townsend St, 4th Floor
> San Francisco, CA 94107
> USA
> (415)869-3103
>
>
>
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>
>
>
> --
> Arnaud Lesueur
>
> LinkedIn: http://www.linkedin.com/in/lesueur
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
Barrow Kwan
ThoughtWorks Inc
410 Townsend St, 4th Floor
San Francisco, CA 94107
USA
(415)869-3103
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070807/a42c9011/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2407 bytes
Desc: not available
Url : http://tp.its.yale.edu/pipermail/cas/attachments/20070807/a42c9011/attachment.bin
More information about the cas
mailing list