[Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
by bstansberry＠jboss.com
The key is acquiring a RL in ClusteredSessionValve:
| // let the servlet invocation go through
| Lock lock = manager.getReadLock(requestedSessionId);
| lock.lock();
| try
| {
| if (isEvent)
| {
| getNext().event(request, response, event);
| }
| else
| {
| getNext().invoke(request, response);
| }
| }
| finally
| {
| lock.unlock();
| }
|
The stuff inside that try/finally block encapsulates the application code's interaction with the session. The lock returned by manager.getReadlLock(...) is the RL from a java.util.concurrent.lock.ReadWriteLock. When any replication activity happens, it happens outside the above block and the corresponding WL is acquired.
Result is, application code will not be manipulating the session when the WL is held. Application code doesn't need access to the RL as it will never be conflicting with the replication code.
Unspoken and unproven assumption here: there is a sufficient benefit to having *guaranteed* lockout of application activity. One benefit is it removes the need for the application to synchronize.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240432#4240432
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240432
15 years
[Clustering/JBoss] - Re: Lost in the documentation UDP->TCP
by bstansberry＠jboss.com
Good question. This topic deserves a wiki page of its own.
Simplest way to solve your problem:
1) Include the following in your command line args that you pass to JBoss:
-Djboss.default.jgroups.stack=tcp
That will change most of the services that use a JGroups channel to use one based on the "tcp" stack instead of the default "udp" stack.
2) The actual JGroups configurations for the "tcp" stack and the "udp" stack are found in the deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml file. For more on the service that configures, see [1]
You can't use multicast, but the "tcp" config actually uses multicast for it's peer-discovery function. It does this because not using multicast requires configuring the addresses/ports of all the possible nodes in the cluster, which is of course environment-specific and doesn't just work out of the box. But, the "tcp" config in jgroups-channelfactory-stacks.xml tries to help. It includes two discovery protocol configurations, one "MPING" that is uncommented and one "TCPPING" that is commented. You need to comment out MPING and uncommment TCPPING.
For more on MPING and TCPPING see [2] and [3].
3) As noted above, not using multicast requires configuring the addresses/ports of all the possible nodes in the cluster. You need to compile this information. The port is the value of the "tcp" stack's TCP.start_port configuration, by default 7600. The address for each node is usually the value you pass to -b when you start JBoss; can also be the value you assign to -Djgroups.bind_addr if you're using that technique to tell JGroups to use a different interface than the -b one. You can also use hostnames instead of addresses.
Gather all these into a comma-delimited list and pass them to JBoss at startup via a system property:
-Djgroups.tcpping.initial_hosts=192.168.0.100:7600,192.168.0.101:7600,192.168.0.102:7600
4) If you are running clustered JBoss Messaging, JBM has their own UDP multicast-based JGroups config they use. You'll need to change that to use the "tcp" config. This is configured in the deploy/messaging/XXX-persistence-service.xml file. (The value of XXX will depend on what RDBMS you are using for message persistence.) Change:
| <mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService" ...>
|
| . . .
|
| <attribute name="ControlChannelName">jbm-control</attribute>
|
| . . .
| </mbean>
|
to
| <mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService" ...">
|
| . . .
|
| <attribute name="ControlChannelName">tcp</attribute>
|
| . . .
| </mbean>
|
[1] http://www.jboss.org/community/wiki/JGroupsChannelFactoryandSharedTranspo...
[2] http://www.jboss.org/community/docs/DOC-10897
[3] http://www.jboss.org/community/docs/DOC-10915
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240430#4240430
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240430
15 years
[Remoting] - clientConnectAddress not working
by mazz
I am using JBoss/Remoting 2.2.2-SP8 and trying to see how it can be used with NAT involved (where a server binds to one address but my clients need to access it over a different IP).
So, here's a simple test I performed to see if clientConnectAddress works.
I have a remoting client that tries to connect to my server using this invoker URL:
socket://10.10.10.10:1000/?clientConnectAddress=22.22.22.22
My clients must go over the IP 22.22.22.22 to reach my server because I bound the server to 22.22.22.22. 10.10.10.10 is a bogus IP but it shouldn't matter, because the client should use the clientConnectAddress for the IP it uses to connect to the server. Right?
But using that InvokerLocator above, it fails. But if I use this:
socket://22.22.22.22:1000/?clientConnectAddress=22.22.22.22
or this
socket://22.22.22.22:1000
it works fine.
I tried stepping through the code in a debugger but I can't see where "clientConnectAddress" is even referenced. Where is that looked up and used?
I assume I'm doing something stupid - I'm hoping someone can straighten me out.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240419#4240419
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240419
15 years
