• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

custering and co-located web and server tier

 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wanted to have your thoughts on this scenario.

My web tier (upto business delegate) and server tier (session facade onwards) are co-located. I mean say am using only local interfaces for the beans. If i still go ahead and deploy similar configurations on a cluster, what does it buy me?
I guess there is no help from cluster wide jndi tree / cluster aware stubs (they w'dnt exist since there are no remote beans in the first place)

I guess I can configure weblogic proxy to route client requests to any of the servers in the cluster. But one request will be addressed by one managed server in the cluster. If that server fails, the request will go unsatisfied as well because that server is not even aware of existance of others.

(If it had been a cluster aware session facade stub, probably the request would have been satisfied)

So coming back to the original configuration, the client might have to re-issue the request and the proxy at that time might redirect it to another server in the cluster recongnizing that the other guy is down?
So I will have some amount of fail-over capability.

I guess I can still have HttpSession replicated between the servers in the cluster.

Is such a deployment strategy encouraged? Would this even qualify as a 'cluster' given that server peers dont really recongize each other.
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My firm belief is that you can certainly use local interfaces in a WLS cluster. What is important is that the web and EJB code is packaged in the same EAR file.

Bear in mind that, as far as WebLogic Server 8.1 is concerned, just about everything can be clustered. The main exceptions are File services and Time services.
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Karthik


I guess I can configure weblogic proxy to route client requests to any of the servers in the cluster. But one request will be addressed by one managed server in the cluster. If that server fails, the request will go unsatisfied as well because that server is not even aware of existance of others.


Not quite true. Weblogic uses a primary and secondary backup to provide failover capabilities. Basically the addresses of these servers are encrypted into session (or cookie) and when the primary failes it will redirect the request to the secondary server. Next weblogic will make the secondary primary and pick another secondary, etc.


So coming back to the original configuration, the client might have to re-issue the request and the proxy at that time might redirect it to another server in the cluster recongnizing that the other guy is down?
So I will have some amount of fail-over capability.


EJBs are replicated in a different way than web components. Like I said for web components weblogic uses a primary-secondary peering approach. For ejbs, as you mentioned weblogic uses cluster-aware stubs. What this means is that client stubs maintain a list of address of all servers in the cluster. Hence if a client request fails, the stub is capable to transparently failover (if the method is declared idempotent) to another instance. In your case, since your clients talk to the web server that calls collocated session ejbs, then you right: your client requests will stick with that server instance. Although you�ll access your session fa�ade through the remote interfaces, rather than the local interfaces, you�re not able to leave the current server instance, because weblogic optimizes the request for collocated ejb objects. You might gain failover benefits though, but I personally like using local interfaces although weblogic allows passing by reference even for remote calls as you�ve mentioned (consider portability, for example).
Bottom line is that with your architecture there are still plenty of benefits for using a cluster, because you can load balance requests at the web server level, either using a hardware load-balancer or configuring the server proxy.


I guess I can still have HttpSession replicated between the servers in the cluster.


As wilth SFSB Weblogic always replicates the session information across the cluster. However for httpSession object it can track the changes made to the session object (looking at the setAttribute method) and therefore weblogic is capable to replicate only those attributes that were changed. On the other hand for SFSBs weblogic will replicate the whole session information, no matter if only one attribute or all of them got changed.
Regards.
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks Valentin and Roger.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic