JBoss High-availability and Clustering Article

Discussions

News: JBoss High-availability and Clustering Article

  1. JBoss High-availability and Clustering Article (45 messages)

    ClusterComputing.org recently published an article by Sacha Labourey, the main designer and implementor of JBoss's clustering features. The article discusses the clustering extensions, pluggable load balancing, how clusters refresh, performance implications, and the future of clustering in JBoss 4.

    e.g.

    "For example, suppose you have a POJO class (Plain Old Java Object) for which you lack the source code, and whose instances provide some kind of stateless service. The following lines of Java code bind a clustered proxy for an instance of POJO in a naming service:

    POJO pojo = new POJO("hello");
    POJO proxy = (POJO)ClusteredRemoting.registerClusteredObject(
              "objName", // identity of this object in the cluster
               pojo, // object for which to generate a proxy
               "DefaultPartition",// name of the cluster
               new RoundRobin(), // load-balance policy
              "socket://localhost:5150"); // transport to be used by the
                                          // proxy

    new InitialContext().bind ("myObject", proxy); // bind proxy in naming
                                                   // service

    Once these steps are performed on the server, any remote client application can obtain a clustered proxy to POJO. That proxy will allow a client to make remote invocations against the POJO instance, and failover to another node if a problem occurs."

    Read Load Balancing and Failover in the JBoss Application Server

    Threaded Messages (45)

  2. My user base is growing large enough that I would like to consider clustering JBoss.

    How will local interfaces effect the clustering methodology in this article?

    Anyone know a good link to some information about JBoss clustering in 3.2.1?

    Nice read. Growing weary of the business strategy and politics in J2EE...hungry for something practical.

    Best,

    John C. Dale
    Down in the Desert, Inc.
  3. John: How will local interfaces effect the clustering methodology in this article?

    It should not affect local interfaces at all, after all, they are local to whatever server (actually, container) they are being called on, so your client code isn't calling those interfaces to start with. The clustering described in the article is client-side load balancing, which means that if the clients are using EJBs directly, that their calls will be spread across the cluster of JBoss servers. In other words, it is an enabling technology so that you can deploy more than one JBoss server and actually have more than one server getting work to do. If I understand correctly, this is the same approach that WebLogic EJB stubs have been doing since 3.x (1999?) or so, and JBoss has been doing this since 3.0 (2002?) or so as well. This approach can work particularly well with fairly stable clusters and stateless EJBs.

    All that said, I think a hardware load balancer is a much better way to go for anything but the smallest of clusters (i.e. two machines in a test environment.) Since a typically hardware load balancer can handle tens of thousands of concurrent connections, and many different applications simultaneously (i.e. when you buy one hardware load balancer, that is probably all you ever need for whatever network segment it is located on because you can "virtualize" it so that it pretends to be any number of servers, each with a fully load-balanced cluster behind it.) Hardware load balancers also take statistics (including what servers are busy based on a number of metrics) into account when load balancing; the WebLogic and JBoss round robin implementations can [theoretically] easily suffer from "convoying", for example. (That is why a "random" load balance, when being done from the client, is much preferable to the "round robin" provided in Sacha's example.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  4. All that said, I think a hardware load balancer is a much better way to go ...


    Can you give us references to hardware load balancers (I think you mean L4 switches) that can perform load balancing on JNDI queries or at AJP13 level between Apache and Tomcat for example ?
    I thought that kind of hardware was only limited to load balance TCP connections in front of web servers.

    Emmanuel
  5. Emmanuel,

    Can you give us references to hardware load balancers (I think you mean L4 switches) that can perform load balancing on JNDI queries or at AJP13 level between Apache and Tomcat for example? I thought that kind of hardware was only limited to load balance TCP connections in front of web servers.

    If you are establishing TCP connections to invoke the EJBs, e.g. from a large number of clients, then a hardware load balancer will work fine. It works even better if the connections tend to be relatively short-lived, as is the case with HTTP connections (sans keep-alive, anyway). Obviously it will not be load-balancing w/in the scope of a single connection, so (like everything else) it's not a catch-all solution.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  6. If I understand correctly, this is the same approach that WebLogic EJB stubs have been doing since 3.x (1999?) or so, and JBoss has been doing this since 3.0 (2002?) or so as well.

    That sounds about right. Last time I checked, what Weblogic lacks is the ability to compose custom client interceptor chains into the proxies. This is how you get really smart proxies that can enable self-healing clusters.

    All that said, I think a hardware load balancer is a much better way to go for anything but the smallest of clusters

    Of course, the primary benefit of this technology is not doing software load-balancing, but rather to implement failover and set up clusterwide singletons (an important feature that Sacha doesn't mention in the article).
  7. Corby: That sounds about right. Last time I checked, what Weblogic lacks is the ability to compose custom client interceptor chains into the proxies. This is how you get really smart proxies that can enable self-healing clusters.

    Heck, there's no custom like having the source, eh?

    I'm not sure what you mean by self-healing clusters, though. We're just talking about failing over remote calls to stateless EJBs, right?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  8. Hardware load balancing[ Go to top ]

    All that said, I think a hardware load balancer is a much better way to go for anything but the smallest of clusters.
    Cameron, I agree and it's good to hear someone say this. (I did mention it in my book.) I think there's been a tendency to reinvent clustering for J2EE. In fact, clustering stateless objects is pretty easy, however you go about doing it, and hardware is a very efficient way to go.

    Of course there are other legitimate reasons for the smarts in EJB stubs in some applications.

    Regards,
    Rod
  9. Hardware load balancing[ Go to top ]

    All that said, I think a hardware load balancer is a much better way to go for anything but the smallest of clusters.

    > Cameron, I agree and it's good to hear someone say this. (I did mention it in my book.) I think there's been a tendency to reinvent clustering for J2EE. In fact, clustering stateless objects is pretty easy, however you go about doing it, and hardware is a very efficient way to go.
    > Rod

    Rod,

    I agree with you and Cameron that hardware load balancer is better for non-small clusters. but I also think that this is true only if load-balancing policy you are using has nothing do with how the software/app.server works. cluster with stateless nodes is very good candidate for hardware load-balancer (you already mentioned this) but if you want to balance the load based on a state or connection that client has to one of the cluster nodes then you might have to implement that logic (load-balance policy) as part of your cluster-aware proxy. I am not talking about J2EE clustering here, I am talking about load-balancing in genereal as it applies to every distributed system besides J2EE. I think it not matter of reinventing cluster but it is something that depends on your platforms' requirements.

    -talip
  10. I'm deploying an ear file with the web applications as the only client to the ejbs.

    war->SessionEJB->EntityEJB-> (DataStore)

    I don't ever expose a remote interface, and only invoke EJB's from/via a simple deligate class from my struts Action implementations.

    I would definitely like to bring-up a JBoss cluster, as the rate of increase in my traffic patterns suggest a need for it in the next 6 months.

    If I understand correctly, since I'm not calling ejb's from many distributed clients, that the clustring described doesn't really apply (as described above, my only EJB clients are packaged in the same war file, and thusly exist in same server/process).

    So, let's assume that my goal is to bring up several instances of JBoss server, and into each one will be my application ear file deployment. Then, I am assuming that I can front-end my instances with apache and some sort of sticky session load-balancer (much cheaper than hardware load balancer ;).

    Assume then, that two users that are on the system are tied to two different nodes in the cluster. Each of these users loads the same piece of data - PersonEJB with primary key 'pid1'. Both instances of the 'pid1' EJB are loaded into the respective containers. Then, both people make a change to the object identified by 'pid1' and commit the change at the same time. How does the JBoss cluster handle this? I'm assuming that the nodes in the cluster are aware of instances of Entity EJBs that have been loaded across the cluster, and that some sort of synchronization process occurse among the nodes in the cluster that ensures that 1) the first of the two updates happens successfully and 2) that the last update in wins, or kicks back an exception.

    Now, assume a scenario wherein a third user is actively working with the same EJB from above (identified by 'pid1'), but is bound to another node in the cluster, and is actively reading data from the person EJB object. When the update occurs, is the user guaranteed that the ejbLoad() method will be reinvoked on this third user's sticky node?

    I hope this makes sense.

    Thanks for any info/insight you/anyone can offer.

    JC
  11. Most of the EJB containers allow you to delegate concurrency management to the database. The best place to add the code to avoid lost updates and improve throughput is to perform optimistic locking using database triggers and use a commit option and locking policy that allows an instance per transaction. JBoss allows you to implement a wide variety of optimistic locking options based on CMP fields, database columns, modified fields, fields that are read in the transaction etc. JBoss also provides cluster-wide entity bean caches and automatic cache invalidation mechanisms.
  12. John,
    This would pretty much depend on the locking and the entity bean caching policy adopted by the EJB container. If the EJB container doesn't do any verified updates then you're at risks of the 2nd update silently overwriting the 1st one unless the tx isolation level is set to serializable(would work for Oracle).

    I don't know about JBoss but with WebLogic 7+, you can configure an Optimistic locking policy and have the 2nd update bail out with an OptimisticLockException which you can catch, refresh now-updated data and retry your update. You can configure simple timestamp based or column based version checks in the DD for this to work. For the 3rd scenario, If you turn cache-between-transactions on for WLS entity beans, any updates to a R/W entity bean in a cluster would refresh the others in the cluster.
  13. I don't know about JBoss but with WebLogic 7+, you can configure an Optimistic >locking policy


    It's very good and important feature of WL. IMHO JBoss doesnt have such configuration option. At least I haven't found any.
  14. Optimistic Locking[ Go to top ]

    It's very good and important feature of WL. IMHO JBoss doesnt have such configuration option. At least I haven't found any.

    As Bill noted, there are many options for configuring optimistic locking in JBoss. More info can be found here:

    http://www.mail-archive.com/jboss-development at lists dot sourceforge dot net/msg32770.html
  15. How does the JBoss cluster handle this? I'm assuming that the nodes in the cluster are aware of instances of Entity EJBs that have been loaded across the cluster, and that some sort of synchronization process occurs among the nodes in the cluster that ensures that 1) the first of the two updates happens successfully and 2) that the last update in wins, or kicks back an exception.

    You configure your CMP Beans to have 'invalidation' support. When you start to commit a transaction that changes the value of 'pid1', it sends a broadcast message to all of the other servers that are running the same container, and tells them that 'pid1' has changed. The servers that receive the message will remove the pid1 instance from their cache, if it exists.

    So, your question is basically, what happens if my pid1 instance gets invalidated while it is enlisted in an ongoing transaction? From looking at the code, it appears, this will cause an exception when you attempt to commit the transaction, but I would want to run a test to make sure.

    Documentation of this feature can be found here:
    http://www.mail-archive.com/jboss-development at lists dot sourceforge dot net/msg30444.html

    Now, assume a scenario wherein a third user is actively working with the same EJB from above (identified by 'pid1'), but is bound to another node in the cluster, and is actively reading data from the person EJB object. When the update occurs, is the user guaranteed that the ejbLoad() method will be reinvoked on this third user's sticky node?

    If you are doing one read per transaction, then yes, ejbLoad will be called because the entity will not exist in the cache once it has been invalidated. But, what happens if you execute:

    <begin transaction>
      <read pid1>
      <pid1 is invalidated>
      <read pid1>
    <commit transaction>

    You definitely want an exception here, so you don't perform the transaction based on inconsistent views of the data. It looks like EntityInstanceInterceptor will throw the exception you want once you attempt the second read, but once again I would test to make sure.
  16. Or, as Meeraj noted, you can configure your CMP container to be Instance Per Transaction and delegate concurrency management to the database. However, you lose the performance benefits of caching if you do this.
  17. One more question...[ Go to top ]

    Hey, thanks for the great information.

    That is how I figured it would work, but wasn't sure.

    Do I have the same configuration options if I use BMP and not CMP? I've elected to use BMP on some entities for performance reasons.

    Thanks again,

    John C. Dale
    Down in the Desert, Inc.
  18. One more question...[ Go to top ]

    Yes, you can enable cache invalidation on BMP containers.
  19. I'm deploying an ear file with the web applications as the only client to the ejbs.

    >
    > war->SessionEJB->EntityEJB-> (DataStore)
    >
    > I don't ever expose a remote interface, and only invoke EJB's from/via a simple deligate class from my struts Action implementations.
    >
    > I would definitely like to bring-up a JBoss cluster, as the rate of increase in my traffic patterns suggest a need for it in the next 6 months.
    >
    > If I understand correctly, since I'm not calling ejb's from many distributed clients, that the clustring described doesn't really apply (as described above, my only EJB clients are packaged in the same war file, and thusly exist in same server/process).
    >
    > So, let's assume that my goal is to bring up several instances of JBoss server, and into each one will be my application ear file deployment. Then, I am assuming that I can front-end my instances with apache and some sort of sticky session load-balancer (much cheaper than hardware load balancer ;).
    >
    > Assume then, that two users that are on the system are tied to two different nodes in the cluster. Each of these users loads the same piece of data - PersonEJB with primary key 'pid1'. Both instances of the 'pid1' EJB are loaded into the respective containers. Then, both people make a change to the object identified by 'pid1' and commit the change at the same time. How does the JBoss cluster handle this? I'm assuming that the nodes in the cluster are aware of instances of Entity EJBs that have been loaded across the cluster, and that some sort of synchronization process occurse among the nodes in the cluster that ensures that 1) the first of the two updates happens successfully and 2) that the last update in wins, or kicks back an exception.
    >
    > Now, assume a scenario wherein a third user is actively working with the same EJB from above (identified by 'pid1'), but is bound to another node in the cluster, and is actively reading data from the person EJB object. When the update occurs, is the user guaranteed that the ejbLoad() method will be reinvoked on this third user's sticky node?
    >
    > I hope this makes sense.
    >
    > Thanks for any info/insight you/anyone can offer.
    >
    > JC

    There are 4 things you can do for entity synchronization

    1) Cache invalidation. This should only be used with read-mostly/read-only beans and is not transactional so it is possible to have concurrency problems

    2) CMP optimistic locking. We have about 6 different strategies you can use

    3) Commit option B or C with CMP <row-locking> (Select...for update)

    4) Commit B or C with JDBC transaction isolation of SERILIAZABLE.

    Bill
  20. I'm deploying an ear file with the web applications as the only client to the ejbs.

    >
    > war->SessionEJB->EntityEJB-> (DataStore)
    >
    > I don't ever expose a remote interface, and only invoke EJB's from/via a simple deligate class from my struts Action implementations.

    Did you consider using war -> EntityEJB -> (DataStore) instead? If not, why? Note this would be equivalent to have your Entity Beans be a Domain Model, instead of just dumb data holders, as required by the Session Facade (anti?)pattern.
  21. This way, I can code to the same interface from all of my presentation deligates, and I don't have to maintain the same home interfaces (I like to cache these on the create of the session bean because the JNDI lookup of the home interface can be expensive) in many different locations.

    Also, some of my clients require that i don't use entity EJBs - I can swap the persistence interface behind the session bean facade without effecting any presentation code as long as I maintain the contract/interface of the facade.

    When I'm refactoring my code, it's nice to go to one place for a particular type of business logic (I like to segment my session bean facades into logical business segments) service. If I distributed them accross my Action classes it would be more difficult to keep track of hundreds of services. A well documented facade is a handy tool for existing and new developers. Bear in mind that the facade doesn't have to be a session bean. You can make a deligate-like facade that just wraps entity bean interface.

    The facade provides the opportunity to combine and inherit transactional contexts. This would get kind of tricky if you wanted to do it via entity beans (high coupling between Entity beans is in and of itself an antipattern).

    I do return my entity bean interfaces from my session bean, so my presentation code can extract information (never update) from the interfaces for read only cases. However, for update I always pass the parameters to be updated, and let the session bean facade do the work of finding the right instance and processing the update.

    To me this is a much cleaner approach, and has proven to be VERY easy to refactor (just recently I spend two hours refactoring ~20 use cases - I owe it all to well defined interfaces).
  22. Ok, your points are valid, but what about the Domain Model alternative (as described in Martin Fowler's book on enterprise design patterns)?

    In this alternative design, all domain logic would be implemented in the Entity Beans, either as instance methods or as home methods. The Struts Action and ActionForm classes would only contain application logic (aka "presentation logic"). (I am assuming business logic = domain logic + application logic.)
    Note that this is a truly object-oriented design (well, not quite, since EJB 2.0 doesn't support inheritance or polymorphism, but it's close enough), as opposed to a Facade-based design, which is more of a "structured design".

    If you are not going to swap your persistence interface, then this is, IMO, a cleaner approach. It's OO, and it requires less code overall. This is how it would normally be done with Hibernate or JDO, I think.
  23. Fair enough about OO...[ Go to top ]

    And you are right about the domain approach. It is quite clean and cohesive to put the business logic with the concept (see also a getter/setter article from javaworld.com a few weeks ago).

    What about the transaction issue?

    I still like the facade pattern because it encapsulates and identifies a cohesive set of business services. Practically speaking, it is useful for caching home interfaces to many different types of entity beans (in fairness this could be done in Action instances, but the service cohesion argument still holds).

    Nice comments. I think both approaches will yield a good user experience. I think my approach might be better with regard to getting software patches out quickly, as well as a lower degree of coupling between entity beans.
  24. When directly accessing Entity Beans from the web layer, you do lose the ability to use EJB declarative transactions (well, not entirelly, since it works the same for the EBs). However, this isn't such a big deal. Typically, each JTA transaction in a web app spans one HTTP request/response cycle. Therefore, you can begin a new transaction at the beggining of the Struts Action method, and complete it (with a commit or a rollback) at the end of that same method call. This can be easily done programatically with a helper class with two static methods, say UserTransaction tr = WebTransaction.begin() and WebTransaction.end(tr), or it could also be done transparently by the MVC framework (in Struts, it should be possible by extending Action in a way similar to what the DispatchAction class does).
    Note that you can still factor the Action method(s), without having to pass the UserTransaction instance around.

    For caching the Entity Bean (local) home interfaces, I use the same ServiceLocator pattern (with a few tweaks) which is typically used with the Session Facade pattern.

    I don't know about the advantages/disadvantages concerning patches to domain logic. Concerning the coupling between EBs, however, it should be higher in the domain model approach, but that only reflects inherent coupling in the business problem. If you use CMP 2.x and declare all the relationships (CMRs) that exist between EBs, then these EBs will be coupled anyway.

    With a domain model approach, you gets rid of all those Session Beans, Business Delegates, and even many of the DTOs (or VOs). And finally, consider the original point of a Facade: to provide a simpler API to a complex existing API; this normally is NOT the case in most business web apps, where the EBs are designed and implemented at the same time as the Facade.

  25. > All that said, I think a hardware load balancer is a much better way to go for anything but the smallest of clusters (i.e. two machines in a test environment.) Since a typically hardware load balancer can handle tens of thousands of concurrent connections, and many different applications simultaneously (i.e. when you buy one hardware load balancer, that is probably all you ever need for whatever network segment it is located on because you can "virtualize" it so that it pretends to be any number of servers, each with a fully load-balanced cluster behind it.) Hardware load balancers also take statistics (including what servers are busy based on a number of metrics) into account when load balancing; the WebLogic and JBoss round robin implementations can [theoretically] easily suffer from "convoying", for example. (That is why a "random" load balance, when being done from the client, is much preferable to the "round robin" provided in Sacha's example.)
    >
    > Peace,
    >
    > Cameron Purdy
    > Tangosol, Inc.
    > Coherence: Clustered JCache for Grid Computing!

    We offer pluggable load-balance policies as well as a RandomRobin policy already defined that you can use.

    Bill
  26. Cameron,

    >Hardware load balancers also take statistics (including what servers are
    >busy based on a number of metrics)

    I have written an algorithm in software for this. It uses only one metric - response time of each node.

    >into account when load balancing;
    >the WebLogic and JBoss round robin implementations can [theoretically]
    >easily suffer from "convoying", for example.

    Not just theoretically! But as I said in WL you can configure the relative
    performance of each node. That will not take any statistics into account can prevent convoying.

    >(That is why a "random" load balance, when being done from the client,
    >is much preferable to the "round robin" provided in Sacha's example.)

    Yes, you are right ! I did some performance tests using several load balancing
    algorithms. Indeed Random policy was better than RoundRobin. You can see the results of my tests here:

    http://www.datapro.lv/~mariso/loadbalancing/

    regards,
    Maris
  27. prevent convoying.


    I meant:
    That will not take any statistics into account but can prevent convoying.

    > Hardware load balancers also take statistics (including what servers are
    > busy based on a number of metrics)

    IMHO Hardware load balancers can use only one metric - response time. I dont think that they can measure let's say CPU usage and RAM consumption of each node. However, if you have "clustering server" than it should be hardware based. Because software solution could be a single point of failure with low reliability. But load balancing software on client side is perfectly OK. Furthermore, advanced algorithms can be implemented in software with much lower cost than in hardware.

    Maris
  28. Unbalanced processing time?[ Go to top ]

    I have written an algorithm in software for this. It uses only one metric - response time of each node.

    > Yes, you are right ! I did some performance tests using several load balancing
    > algorithms. Indeed Random policy was better than RoundRobin. You can see the results of my tests here:
    >
    > http://www.datapro.lv/~mariso/loadbalancing/

    Interesting read. But:

    Correct me if I am wrong, but didn't you distribute load across identical tasks regarding CPU/processing time requirements?

    In my experience your assumptions fail within an unbalanced application environment, such as partial application failure ("sorry, please come back later" dialogs) or huge differences in application processing time (as seen with WebServices).

    Jens
  29. Unbalanced processing time?[ Go to top ]

    Correct me if I am wrong, but didn't you distribute load across identical >tasks regarding CPU/processing time requirements?


    In those tests, yes. But there is no assumption about identical tasks in the algorithm. It could work with different tasks without problems.

    Maris
  30. Unbalanced processing time?[ Go to top ]

    In those tests, yes. But there is no assumption about identical tasks in the algorithm.

    > It could work with different tasks without problems.

    Sure? Sounds a little bit too academic to me;).

    Just a simple example.

    Imagine a partial app failure. Let's say a web enabled application runs into a backend communication problem. We show a static, user friendly message explaining "sorry, we can't handle the request". Response times will be way faster than processing the request for real. How do you deal with this just by looking at the response time?

    In my opinion you can't without understanding application charateristics.

    Jens
  31. Unbalanced processing time?[ Go to top ]

    Response times will be way faster than processing the request for real. How do >you deal with this just by looking at the response time?

    > In my opinion you can't without understanding application charateristics.

    Yes, you are right, in that case my algorithm would learn that a task requires
    a lot less time than in a real situation.

    But the algorithm is self-learning neural network. So when the backend system
    is alive again the neural network will adapt to new conditions.
    It would take some time (about 30 remote requests) to learn, but after that load balancing would be optimal again. The same scenario happens if cluster topology changes (a node goes down, a new one joins the cluster).

    Higher biological systems (like humans) are mostly based on neural networks too.
    Things like an ability to swim or walk upstairs are neural netowrk based. Of course a lot more complex neural networks than those we can implement.

    Maris
  32. Unbalanced processing time?[ Go to top ]

    Not to be pedantic, but neural networks are models inspired by (what little we know about) mammalian brain processing. The strong AI implications of the statement "Higher biological systems (like humans) are mostly based on neural networks too. Things like an ability to swim or walk upstairs are neural netowrk based. Of course a lot more complex neural networks than those we can implement." is a bit of a stretch.

    Anyway, this is very cool work and highly applicable.

    Greg
  33. Hi Maris,

    That is a very interesting approach, and I liked the page (the link you gave.)

    Did you consider ways to estimate actual loads on the server? I've wondered if a low priority thread could emulate a load measurement indicator, for example.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  34. With respect to the very first post, John, I would be very interested to know how much load JBoss is able to handle, in terms of concurrent users using the topology that you have described: Struts Action --> Session Facade --> EJB -->Database.

    I know this will be hardware specific too, but perhaps you could post some details?
    cheers,

    Brian
  35. JBoss Load Results...[ Go to top ]

    I'm using PIV 2.6 ghz processors with 500 meg of ram and 7200rmp raid'ed drives (build them via a local computer shop for ~1g apiece) for the app server.

    I use a PII 233mmx with 256 meg of ram and 7200rpm drives for the database (running mySQL).

    I have some bandwidth limitations from the external net, but internal subnet tests have yielded the following results reliably:

    Use Case:
    (login->loadlist->loaddetail->updatedetail->reloadlist)

    Users:
    40 (segmented in 1/3 across available data, so operations on the same data occurs).

    #cluster nodes:
    1

    Average response time under load with no thinktime:
    ~.9 seconds

    System ramp-up time: 1.5 minutes

    Use case implementation uses entity EJBs for ALL persistable data, and uses BMP.

    Hope this helps.
  36. JBoss Load Results...[ Go to top ]

    Thanks John,
    that's great. This configuration is just like mine. I have a few little questions if you don't mind.

    1) Any problems with mysql and transactions?

    2) How do you do your use cases? Eg, struts test case, cactus etc.

    thanks very much,
    Brian
  37. Use Case Implementation...[ Go to top ]

    mySQL released a version with transaction support that seems to work pretty well. I haven't yet experienced any data integrity issues or data loss due to the transaction handling of mySQL.

    You can find the latest release here:
    http://www.mysql.com/downloads/mysql-4.0.html

    I first document my use cases using PoseidonUML (www.gentleware.com). I think about the problem landscape and identify several top-level use cases. Then, I identify descrete use cases for each top level use case and do another sub-diagram for those. For each of those, I quickly do a system interaction diagram/activity diagram with lots of comments so if I lose my train of thought or get interrupted, a quick glance at that will reorient me.

    Then, I start modeling workflows with code. So, I'll go into my struts conf file and quickly identify the action classes for my current use case and group them together with comments. Then, I stub-out all of my html/jsp and Action classes, and identify data members (this assumes a relatively established data model - if no data model, then I vet/start there as I'm developing my use cases). After I get that stubbed, I identify entities that will be required. I stub those out. Then, I start developing from the first Action in a workflow-down, and so forth for each member of a use case's workflow.

    Hope this helps.
  38. Use Case Implementation...[ Go to top ]

    Thanks again John. Very helpful. Can you tell me how you test these use cases though? Do you use junit tests, struts-test cases or what? Thanks for all your helpful replies,
    Brian
  39. Wow, I was already on turkey after one week without any JBo$$ headline on TSS.
  40. The decision process[ Go to top ]

    The decision process is not computationally intensive


    I have written load balancing algorithm for JBoss as base of my university thesis. The algorithm is based on artificial neural network and is computationally intensive.

    Still it produced much better (up to 176%) cluster performance than static load balancing algorithms. In heterogeneous cluster of course.

    My algorithm was able to learn about each server performance on the fly. WEBLogic supports optimal load balancing among cluster servers with different performance. However relative power of each node must be configured manually and has no no way to detect if load of any node changes dynamically. JBoss 3.x doesnt provide even that kind (static) of load balancing for heterogeneous network.

    http://www.datapro.lv/~mariso/loadbalancing/

    Maris Orbidans
  41. Fail over - Does it really work?[ Go to top ]

    I have a problem with the fail-over scenario in Sacha's paper.
    He starts with server1 and server2; both servers are taken down and replaced by server3 and server4.
    Sacha affirms that the client can't have a stale view of the cluster because it refreshes its view with each request.
    But what happens if server1 and server2 are replaced while the client is idle? I.e. no request take place during that time.
    The next request the client makes will go to server1, fail, then go to server2, fail again, and that's it. The client won't know that the cluster is now using server3 and 4.

    An I missing something here?

    v.
  42. Fail over - Does it really work?[ Go to top ]

    Your scenario is unlikely, but yes it could happen.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  43. Fail over - Does it really work?[ Go to top ]

    But what happens if server1 and server2 are replaced while the client is idle? >I.e. no request take place during that time.

    > The next request the client makes will go to server1, fail, then go to >server2, fail again, and that's it. The client won't know that the cluster is >now using server3 and 4.

    The client will discover new servers via IP multicast message.
    I have tried this with two servers.

    Maris
  44. Fail over - Does it really work?[ Go to top ]

    How will a client application discover new servers through IP Multicast??? I dont get it. The client only can use its stub to discover its primary or secondary server. If its stub is not updated, how will multicasting on the server side help??? Maybe you know, something I dont.
  45. Fail over - Does it really work?[ Go to top ]

    copy-paste from JBoss clustering docs:

    In highly dynamic environments, where many servers start, stop and are moved,
    solution can still be frustrating to configure. Consequently, a new feature, called
    discovery?, has been set up. If the property string java.naming.provier.url is
    servers it mentions are not reachable, the JNP client will try to discover a bootstrap
    JNDI server through a multicast call on the network. Thus, if you have a LAN
    WAN is configured to propagate such multicast datagrams, the client will be
    valid HA-JNDI server without any configuration. The auto-discovery feature uses multicast group address 230.0.0.4:1102.
  46. What about load balancing?[ Go to top ]

    Nicely written article, but one remark: it only discusses failover and does not deal with load balancing (although the title would suggest otherwise).

    Anyway, I see some issues with a client side approach to load balancing. As the article explains it works nicely for failover scenarios, but how will load balancing be done?
    I don't really see a way for the client to make an informed decision about which server to select to do proper load balancing. Can anybody explain the alogithm that JBoss uses for load balancing?

    Erwin Vervaet
    erwin@ervacon.com