Hi Zlaja
On 7/16/11 4:04 AM, Zlatko Josic wrote:
> Hi Shreedhar,
>
> Thank you very much for your responses. It helps me. I have couple of
> questions more.
>
> 1. I have researched GlassFish source code litle. I have found that
> both sessions, web and ejb, use BackingStore for storage. I also have
> found that GlassFishKeyMapper.java class extends DefaultKeyMapper.java
> from shoal-cache library that I also have researched. Does GlassFish
> server use shoal-cache under the hood for replication of its sessions?
Yes that is correct. GlassFish has a HA-SPI of which there is an
implementation that uses Shoal Cache from project Shoal.
>
> 2. I have sent a post to glassfish user group but I haven't got any
> answer.
Sorry that there has been no response. I have asked our HA architect to
respond to you there as I am not very familiar with that part of the code.
Thanks for continuing to post questions to clarify your understanding.
Shreedhar
> The question is glassfish related but also clustering related so I
> will repeat it here.
> It is abount stateful session bean clustering. Glassfish uses
> checkpoint method to replicate bean's state to replica node. Suppose
> we have two nodes. Node A and node B. Node B is replica for node A.
> Glassfish calls checkpoint method at the end of transaction(commit or
> rollback) if I understood it well.
>
> Now suppose we have stateful session bean named TestBean with method
> increment. Bean uses local transaction, not XA. Bean has field named
> counter of long type and initial value is 1. Calling the increment
> method of bean increments field counter by 1 and writes a new value to
> a database.
>
> What will happend in the case when node A goes down immediately after
> commits transaction ( node commits trnsaction successfuly but hasn't
> replicated state to node B). Now client's ejb proxy detects node A has
> gone done and redirects call to node B. At node B counter value of
> TestBean is diffrent the the value it the databaase. First does it
> work in the way I've discribed at all? If does how does node B sync
> the values? Is it programmer's responsibility?
>
>
> 3. Just to comment point 3 from previous post. We use permanently
> connected clients because of speed.
>
> Thank you once more.
>
> Zlaja
>
> On Sun, Jul 10, 2011 at 8:07 PM, Shreedhar Ganapathy
> <shreedhar.ganapathy_at_oracle.com
> <mailto:shreedhar.ganapathy_at_oracle.com>> wrote:
>
> Hi Zlaja
> I have put in responses below.
>
> On 7/9/11 10:04 AM, Zlatko Josic wrote:
>> *
>> *
>> First, thank you all. Now, I get idea about load balancers.
>>
>> My company has developed own server we use for recharge prepaid
>> accounts for mobile phones and it works fine.
>> System now has 2000 clients permanently connected to the server.
>> Now we want to add clustering feature to this server.
>> I have explored how clustering/shoal is used in GlassFish server
>> and have some questions.
>>
>> 1. GlassFish uses Shoal for web sessions and ejb stateful states
>> replication and etc. Suppose we have a cluster of three nodes,
>> A,B and C.
>> If user writes some data to web session on node A does the result
>> of the write operation going to replicate on nodes A and B.
>
> Spreading sessions across all instances in a cluster would
> eventually become a scaling problem either when large number of
> users become part of the system or a limited number of users send
> in large number of requests.
>
> The shoal replication algorithm for GlassFish employs a
> consistently scalable approach by replicating each request under a
> user session to one replica among the cluster of instances, using
> a consistent hashing algorithm.
>
> This ensures that for each session sent to A, B or C, the data is
> replicated to one replica partner for that session. For instance
> session 1 sent to A may be computed to replicate to B, session 2
> sent to A may be computed to replicate to C, while session 3 sent
> to B may replicate to C and so on.
>
> This ensures that all data is replicated in a consistently
> distributed manner without loading one particular instance as a
> buddy partner for another instance and also not spreading the data
> to all instances.
>>
>> 2. Suppose that only two nodes work in the cluster, A and B. Now
>> we start third node, C. After C node started would it ask the cluster
>> for web sessions to be replicated on it, node C?
> To avoid spreading all sessions across the cluster, any new
> session sent to A or B may have a computation result of
> replicating to C. Likewise, any session sent to C will now get
> computed to be replicated to A or B.
>
>
>>
>> 3. As I mention above all ours clients are permanently connected
>> to the server. Suppose we have cluster of two nodes, A and B.
>> Also we have a client
>> connected to node A (the client has created socket connection to
>> communicate to the server. We have Mina based connectors on the
>> server) .
>> At some moment at the time node A crashed. Does the client has to
>> create new socket connection to work with node B or it is
>> possibility of
>> load balancer to dispatch request to node B? I am not shure if it
>> can work at all because at that moment node B has not server's
>> socket that is pair with
>> the client's socket.
>
> The way I see this working is A, B and C are fronted by a Load
> Balancer. The clients only know about the LB and do not know about
> any of A, B, C or any other new instance you add as you scale up.
> From a security standpoint, this is also safer since details of
> your cluster are not exposed to clients on the internet.
>
> The LB proxies the request to any one of the A, B or C instances.
> Lets assume it sent a new session to A. When you set up the LB for
> sticky sessions, all subsequent requests under that session will
> be sent by the LB to that instance A, for that session. The
> session's data is replication by instance A's replication module
> using the consistent hashing algorithm - Lets assume that instance
> A replicated to instance C for that session.
>
> If instance A fails for any reason, the LB will route/failover the
> request to another instance, say B, (based on its routing policies
> - typically round robin). If this is a GlassFish cluster, instance
> B's web container will receive that request and try to access the
> session in its session cache and will not find it, and as a result
> will ask the replication module in B to find this session's latest
> data. The replication module will now use the consistent hashing
> algo to compute which instance was the replica for this session
> and get C as a result - it will send a request to C to load the
> latest data of that session and return it to the Web Container to
> retain it in its cache. Subsequent requests will be sticky to
> instance B until it fails or is stopped by the administrator.
>
> As you can see above, the Sticky Load Balancing allows you to
> ensure a session continues until it is timed out for a given user.
> It does not require you to have long running socket connections -
> you only need a protocol to auto re-login a user when the user
> sends session data from the client when the session has timed out
> on the server end. And clustering with replication allows you to
> scale out as your user base grows.
>
> Hope this helps. Let us know if you have more questions. If you
> are a GlassFish user, you can also post GlassFish related
> questions to users [at] glassfish [dot] java [dot] net email address.
>
> Shreedhar
>
>>
>> Thank you for any idea, link,...
>>
>> Zlaja
>>
>> On Fri, Jul 8, 2011 at 5:10 PM, Shreedhar Ganapathy
>> <shreedhar.ganapathy_at_oracle.com
>> <mailto:shreedhar.ganapathy_at_oracle.com>> wrote:
>>
>> Wow I am impressed with the community chipping in folks.
>> Thanks very much for responding to this question.
>>
>> Zlaja, as mentioned by Jorge and Sri Narayanan, the load
>> balancer can be anything from Apache with mod_jk to Linux HA
>> to many others in the open source and closed source market -
>> most of these support Http an TCP protocol in plain text and
>> secure mode through ssl.
>>
>> Cheers
>> Shreedhar
>>
>> On 7/8/11 6:01 AM, Jorge Falcão wrote:
>>> It's HTTP based searvice?
>>> You can integrate your app with
>>> http://www.jboss.org/mod_cluster
>>>
>>> On Fri, Jul 8, 2011 at 8:31 AM, Sri Narayanan
>>> <sri.narayanan.gce_at_gmail.com
>>> <mailto:sri.narayanan.gce_at_gmail.com>> wrote:
>>>
>>> Usually any clustered design has Load Balancer and it
>>> has nothing to do with Shoal.
>>> Shoal is just a clustering framework.
>>> u can have a look at hazelcast also .
>>> The design has to based on the logic
>>>
>>>
>>> On Fri, Jul 8, 2011 at 4:33 PM, Zlatko Josic
>>> <zlatko.josic_at_gmail.com <mailto:zlatko.josic_at_gmail.com>>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I would like to include clustering in Java SE
>>> application. Do I need load balancing in front of
>>> cluster?
>>> Does Shoal support load balancing? If not what is
>>> the solution for load balancing? Should I use any
>>> other framework
>>> for load balancing or what?
>>>
>>> Thanks
>>> Zlaja
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> SriNarayanan
>>>
>>>
>>>
>>>
>>> --
>>> Jorge Falcão,
>>> Intelie - Inteligência em operação
>>> http://www.intelie.com.br/
>>> 55 21 2240-1193 / 9373-8671
>>
>>
>