• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

what is single point of failure?

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please give me a definition.
thanx!
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gagahost - your name does not comply with the JavaRanch naming policy. We require the use of real names, preferably your own.
I see that you have been asked to change your name several times in the past:
  • October 18, 2002
  • October 01, 2002

  • Both of those requests were on posts you had created, so you should have seen them. Since you do not wish to comply with our naming policy, your account will now be closed.
     
    Sheriff
    Posts: 5782
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Any monolithic component that acts as a gateway to other components is perhaps a good example of a single point of failure. For instance, a single (Remote)session bean acting as a facade and used by delegates constitutes a single point of failure.
     
    Greenhorn
    Posts: 7
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Ajith Kallambella:
    Any monolithic component that acts as a gateway to other components is perhaps a good example of a single point of failure. For instance, a single (Remote)session bean acting as a facade and used by delegates constitutes a single point of failure.


    Thanks a lot for your help!
     
    daniel guo
    Greenhorn
    Posts: 7
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    hi,Ajith Kallambella
    Can you tell me what are pros and cons about single point of failure?
    Thanks!
     
    Ranch Hand
    Posts: 194
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Ajit,
    Single point of failure is architectural related or application related?
    If a single machine in a network serves the request, and if any failure (hardware or software), it is called single point of failure. This is what I read previously somewhere. Can you please brief about it, as I don't know much about it.
    Thanks in advance Ajit.
    Regarrds,
    Ganapathy, S.
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Daniel & Ganapthy,
    The "pro" (if you can call it that) of a single point of failure is that it can be quicker and easier to set up and maintain.
    To get around the single point of failure, you may decide to run multiple copies of your application. You then have to work out how to handle the fact that a user's transaction may be going to either application - how do you maintain your sessions across different instances of the software? (can your container handle that for you?). This can then get compounded if your computer now forms your single point of failure, and you set up multiple computers to run your multiple instances of your application (possibly at different sites).
    The "con" for a single point of failure is that you have a single point of failure. If you have a power outage in the only location where you are running your application, then your application stops. If your company is relying on getting bookings through your application 24 hours a day, 7 days a week, you could loose thousands of dollars while you have this outage. If you have removed the single point of failure (in this case by having a second machine in a different location), then you continue to receive bookings while one machine is off line.

    Single point of failure is architectural related or application related?


    It can be either.
    The ideal situation is to have multiple instances of your application running on multiple machines at multiple sites. However many companies are not willing to accept the time it would take to engineer such a solution, nor are they willing to meet the costs. So it usually comes down to a tradeoff on what sort of outage they are willing to accept, and what you can do to fix what they are unwilling to accept.
    This may mean that when you design your standalone application, you may have to think about making it as robust as possible, so that it still continues to run even if it gets bad data (nothing worse than an application that crashes at 6pm on a Friday night, and doesn't get restarted until 9am the following Monday). And then possibly design it so that it can be automatically restarted if it crashes (so no GUI on your server requiring user interaction). The design it to come back up in a suitable manner - how much of the state it had before the crash can be restored?
    Or management may not be happy with the 30 second - 1 minute outage that having an application restart may cause. So you may have to have multiple instances of your application. Then you have to decide whether one is a failover for the other (may reduce the outage to 5 seconds or less), or whether they both run simultaneously (so perhaps zero outage). But then you have to design your application so that such a configuration is possible.
    And, as architects, we have to be aware of the platforms we will run on. (The best written application in the world will not behave very well if it is working on old equipment in a non ventilated dusty room. ) So if management have said that your application is mission critical, and that no outage under any circumstance is acceptable, then you may have to look at the hardware - do you go for Stratus (or Tandem) equipment in multiple locations?
    These are all just questions you might have to think about. Basically you want to identify any point where a single failure can stop your application from running. And then decide whether to fix it or not (or more accurately: identify the issue to management so that they can decide what to fix). Even in that multi location scenario I just gave, you may still have a single point of failure if the second machine requires the internet connection at the first site to be working.
    Regards, Andrew
     
    reply
      Bookmark Topic Watch Topic
    • New Topic