Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gmail's Second Major Problem

kapilkale.com

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Gmail's Second Major Problem

#51

Post by UnoriginalGuy »

rz2k wrote: post #8
plg wrote: post #3

i wish some major computer company would release an easy-to-use plug and play server product that would enable consumers to run their own mail servers on cheap hardware, just by toggling a switch just imagine... no ads, no privacy concerns, complete control. if they were smart they would include some sort of automatic backup program that runs in the background and saves everything every once in a while, a backup that…

How come Zimbra seems to be so widely disparaged? Spam control requires a little more intervention than with Gmail, but I've found it straightforward enough to set up once, then do nothing else for a couple years.

Because Zimbra only supports Linux, is designed for large enterprises, and requires special client-side programs to be installed just to do things like calendar sync.

It is fine if you control the whole ecosystem, but ironically in most scenarios where that is the case you're running Windows Active Directory anyway so therefore might have well pay a few pennies for Exchange CALs.

Re: Gmail's Second Major Problem

#52

Post by erock »

buster wrote: post #28
kapilkale wrote: post #24

Earlier quoted context omitted.

Sure, but email is still the preferred form of external communication with customers and clients.

Doesn't change the fact that this preferred form of communication by no means guarantees delivery in a certain timeframe. It's not a google problem. The email can be "stuck" in every place between you and the recipients mailbox.

to highlight this, I can think of an emails that got delivered YEARS after I hit send. This happened once in almost 20 years of emailing, yet in still happened. This probably occurred about 6 years ago.

Re: Gmail's Second Major Problem

#53

Post by codeka »

Even though I agree with people here saying that you can't expect 100% instantaneous delivery from SMTP, this incident was actually posted on the Google Apps status dashboard ( http://www.google.com/appsstatus#hl=en&v=issue&ts=13... ).

So it's not even like this is some common problem that happens all the time and Google is ignoring. No service is perfect and outages happen.

Re: Gmail's Second Major Problem

#54

Post by kapilkale »

codeka wrote: post #53

Even though I agree with people here saying that you can't expect 100% instantaneous delivery from SMTP, this incident was actually posted on the Google Apps status dashboard ( http://www.google.com/appsstatus#hl=en&v=issue&ts=13... ). So it's not even like this is some common problem that happens all the time and Google is ignoring. No service is perfect and outages happen.

Ah- there IS a status page. Thank you.

Re: Gmail's Second Major Problem

#55

Post by bradleyjg »

monsterix wrote: post #37
neya wrote: post #30

The author is furious about a technology that was not designed for instantaneous delivery (SMTP) and fumes about it, because it isn't instantaneous. What's worse is, he quickly assumes goes into some kind of 'super-hero mode' and makes a pretty heavy claim that this is Gmail's second biggest problem . I think this is the best approach - If someone hands over you a free glass of wine, which they've tried their level b…

No doubt SMTP is asynchronous, but a lag of 115 minutes? For a consumer that is way too high to live with, whatever say the standards. But obviously the title of the article and probably the topic borders on a flame-bait.

I guess you weren't around for FIDOnet. It could be days before you got an email.

Plus we had to walk to school in the snow - uphill both ways.

Re: Gmail's Second Major Problem

#56

Post by RyanZAG »

Google's servers are incredibly complex. Probably too complex - the more complicated they make their infrastructure (datacenter failover, region failover, bla bla) the more unstable it seems to get.

Google uses a very bureaucratic code commit system that requires sign offs from different people. This process takes a long time, and devs can't move onto the next step until the previous step has been accepted [1]. While this system is awesome for catching the localized bugs (no buffer overflow is going to get past that kind of code review), there is a major tradeoff. A dev can only keep so much state in mind when building architecture. If he is only working on the problem once a week with large time gaps, is he not going to lose track of important pieces of the puzzle?

This is probably the age old problem - if you make something that is too clever for even the creator to fully understand, how are you possibly going to make sure it is bug free? The problem being some delay between Google servers hints at an inter-region datacenter problem. I wonder if anybody at Google even understands the entire failover and interlinked data center system completely?

[1] http://www.splinter.com.au/2012/12/26/behind-enemy-lines-goo...

Re: Gmail's Second Major Problem

#57

Post by hurstdog »

The issue that you're complaining about was due to the incident linked at [1].

I can't go into the technical details as to why this happened, but I can roughly explain that it was due to the CAP theorem, essentially "Consistency, Availabilty, Partition Tolerance. Choose two." [2]

Furthermore, you have to choose partition tolerance [3]. The delivery delays that were seen yesterday is because we choose consistency over availability in our systems.

In fact, most of the outages I see people complain about on Hacker News related to Gmail are because we won't sacrifice consistency of user accounts. It's a different problem than huge scale serving of web search indexes or facebook timelines because in those cases if you're missing a few entries most people won't notice or care. When you're searching for an email, you know what email you expect to find and you'll get angry if it isn't there.

Users won't stand for an email showing up one day, disappearing next hour, and then coming back later (which is what could happen in some designs for eventual consistency when serving from different datacenters).

Thus, Gmail availability is lower sometimes because we make sure that all of your data is there all the time. We're insane about it, and we have huge jobs that run constantly on our systems to ensure that we're even resilient to bad hardware. With those we regularly find single bit errors and bad CPUs.

So, as a Gmail engineer, I'm sorry that there were delivery delays yesterday, and all I can say is that every time these happen we tweak and redesign our systems to make these more rare and to improve Gmail's uptime. We'll never have the snappy response and perfect uptime[4] of a computer under your desk. But at the same time a hurricane could take our one of our datacenters and we won't lose your data.

-Andrew, a Gmail Engineer.

1. http://www.google.com/appsstatus#hl=en&v=issue&ts=13... 2. http://en.wikipedia.org/wiki/CAP_theorem 3. http://codahale.com/you-cant-sacrifice-partition-tolerance/ 4. For some definitions of perfect.

Re: Gmail's Second Major Problem

#58

Post by nessus42 »

neya wrote: post #30

The author is furious about a technology that was not designed for instantaneous delivery (SMTP) and fumes about it, because it isn't instantaneous. What's worse is, he quickly assumes goes into some kind of 'super-hero mode' and makes a pretty heavy claim that this is Gmail's second biggest problem . I think this is the best approach - If someone hands over you a free glass of wine, which they've tried their level b…

> If someone hands over you a free glass of wine, which they've tried their level best to make it perfect, you just drink it instead of trying to suddenly become a food critic

I think this is a bogus argument. If someone hands me a free glass of "wine" and it turns out to be undrinkable swill instead of wine, I'm pretty sure I would point this out.

With regards to email, people expect email to be fast, and if your email servers routinely take a long time to make a delivery, you are not giving people what they would expect from your service, free or not.

I say this as someone who was a sysadmin for a number of years and maintained email servers. If our email servers took two hours to deliver a piece of email, and it was the fault of our servers, I would have considered this to be an urgent issue to resolve.

All this being said, I'm pretty happy with Gmail myself.

Re: Gmail's Second Major Problem

#60

Post by buster »

sskates wrote: post #46
buster wrote: post #26

Whaaat, SMTP != Instant Delivery!? You must be joking! As much as i can understand the pain of an email not being delivered after 2 hours this seems to be too much drama. "happens 2 times in a month" is not a "major problem" for a free service especially since i suppose this user is part of a rather small minority. I never noticed substantial delivery lags myself over the past years myself. Anyway, if you say "i'd pa…

As funny as you think it might be to charge $50 a month for guaranteed quick delivery, this is exactly what he actually wants. Large random delays in delivery are costing him way more, so he's willing to pay to fix the pain. Instant delivery isn't in the RFC, but conformance with the spec is not something he cares about. He cares about fast delivery.

Just as you say: What he wants and what he has have nothing to do with each other. I want my pocket to contain 1 million dollar. It's not how it works, unfortunately :(

Look, there are many many reasons why an email may not arrive in time or at all at the destination. To say "i lose so much money but i rely on such an unreliable protocol" is just not the mistake of google.

And as i said, for 50$ dollar you can easily buy 2 virtual machines in two different locations, one domain and have virtually a no-downtime mail service for your own. Add some roundcube, clamav, spamassassin and there you go. Setup takes a bit, fine, but that's about it. I guess it wouldn't even take that long. It won't guarantee delivery as well, but mails won't be stuck in some MTA ;)

Post reply on HN