Email -> SL Very Slow Currently?

If it were JUST this one issue, No, I wouldnt either. This issue not being resolved is just one of TOO MANY now, which arent getting fixed.

If I were at least able to stay logged in or able to do anything other than stand there while logged in I'd at least have something to do ....

**hisses**

The Linden Strikes Again

I only noticed this today, the thread I mean, but this morning my time (around midnight SL time) I was getting 'queuing' of emails. I'd get nothing for 3-10 minutes then, if I'd been silly, I'd get them all come through together, just like buses! The first time I saw this I wanted to check it was all working, so I got 4 emails come through together, but the first was delayed 3 minutes despite the fact I was checking every 10s or so.

More irritatingly I was getting the same pattern repeatedly - almost like it was my home email which polls it's server(s) every 10 minutes and grabs all the email that is there rather than a faster industry standard server set up...

I think that the expectation that an email message be delivered instantaneously is an expectation of service that stretches the bounds of the intentions of the designers of the Internet Email system, the sendmail queueing system and perhaps even the SMTP protocol.

The expectation for email that is commonly acccepted on the Internet is 3 DAYS. If you need more immediate communication, you will need to rely on something else, such as a direct tcp session (HTTP?) protocol.

Email goes through many different layers, and the mechanism through which it is delivered has too many failure points to be considered a reliable transport for MUST_HAVE data. If you are relying on email for your application to work properly and instantaneously, and without expecting massive queue dumps, you need to rethink your application architecture.

I don't think anybody here is expecting email to be instantaneous. However, because of the borked out-world communications we have (until 1.9.1, when ever that arrives), it's not at all unreasonable to expect it to arrive within a few minutes. In fact, LL have really had a very stable and responsive email delivery service until the last couple of weeks. And they have acknolwedged a problem that's causing it, but they just don't appear to have fixed it yet. We all know that periods of instability with email are possible, what's happened here is that a problem was known about, we had to wait for a supposed fix because the grid had to be down to do it and, it appears, that either hasn't happened or hasn't worked. So now we have to wait again I guess for the grid to be taken down.

I doubt if anybody in their right mind would accept 3 days as a common expectation for email delivery in normal operation. That's quite laughable and bears no relationship to the reality of email delivery we encounter each and every day.

If XML-RPC had been a complete implementation, as promised, people wouldn't be relying on email for jobs that, really, email shouldn't be doing anyway. 1.9.1 will hopefully resolve this with llHTTPRequest(). However, in practice, as that would also appear to be fundamentally borked in terms of the number of requests an object owner can make, sole reliance on that might also be unfeasible. We'll have three ways of communicating with the outside world then:

(1). One incomplete (XML-RPC)
(2). One subject to random instability (Email)
(3). One subject to strict usage limits (HTTP)

So take your pick! Either way you go, the system doesn't exactly make it easy

I'm not expecting instantaneous - but I am expecting a service that worked one way a few weeks ago to remain working that way. Occasional glitches accepted and excepted of course.

The system I was using had been set up and extensively tested. I typically got round trip times measured in seconds - 5-10 not being unusual, sub-15s 99%+ of the time. It could be better, but really very acceptable for the application I was developing. With that in mind I continued to develop email communications because there are times when sending 1,000 characters at once is just better than 255 characters split across 4 messages, particularly when it's fast enough to be useable.

Then my partner for this project did some work so I took a break from that project. Came back today and got 10 minute turn around times. It makes a project that was working smoothly suddenly work horribly... and raises the ugly, ugly spectre of having to recode a LOT of code at each end to get it to work acceptable, to probably recode AGAIN when 1.9.1 is finally unleashed on an all-to-suspecting world.

From reading this thread, it seemed to me that the 'minutes' expectation WAS being met. The longest delay I have read on this thread was 10 minutes, which is certainly an understandable delay.

Because email must travel through gateways (DMZ hosts, virus scanners, etc), a delay of minutes can be reasonable, depending on system load.

The two complaints I've read so far seemed to be that email can arrive in 'bunches' as queues empty out after a delay, and the delay itself.

All I'm saying is that the delay is normal and expected. 3 Days is probably pushing it a bit, but most email systems WILL queue email for up to 3 days before sending an NDR back to the originator. And that's how they come out of the box.

Just because something works fast today doesn't mean that you can continue to expect it to work that way tomorrow, especially if the very nature of it does not have 'fast' as one of its design qualities. Email was never designed to be fast. That it normally is says a lot about the progress of the Internet, but as security becomes more important, expect 'fast' to become an option when it comes to email.

A simple mail bomb can take email out for hours, and that should be a design expectation if using it for communications. The system works as designed, and I think that the people on here who are moaning about 'Consumer Protection' laws, etc... are full of hoo-hocky and need to stop complaining and accept what is given.

If LL can fix it, I am sure that they will. If the delay is caused by the installation of 'SPAM' guard or some griefer mail-bombing their servers, though - it won't get 'fixed' because it's not broken. Your applications will need to learn to deal with the delays. Other 'purchase protection' license software on the net deals gracefully with email delays. One Mobile provider didn't get me a license key for their software for 8 hours due to email delays. But the design was such that I knew to expect possible delays.

Duke

Actually delays have been anything up to 40-50 minutes, that's what I've been seeing.

Most of what you're talking about, however, doesn't really apply in this particular situation. We're talking about an email sent from outside SL to an object into SL. It's getting to SL's external mail server fine and dandy, it's SL's internal routing that's causing the issue, something that they're aware of but are still yet to fix after 2 weeks. Once it's into their network, their systems just aren't dealing with it correctly (and, according to the Linden who posted on this thread, it's nothing to do with load).

In addition, in a system where our options are limited, we have to make use of those limited techniques we are given. In a perfect world email would be the last method I'd use to transfer blocks of information between systems, but this isn't the real world unfortuantely. Even when llHTTPRequest() appears it's not really a panacea for out-world <-> in-world communications. It's limited to something like 20 connections per 200 seconds per avatar, so it's easy to see that relying upon this in products could also give issues. You have no way of knowing how many other items a user has that also use llHTTPRequest(). So even when that arrives, we're still stuck in a loop of choosing between several poor communication tools.

As I said before, I don't expect perfect service all the time. What I do expect is that when a problem is highlighted that it's acted upon quickly and not left to continue for 2+ weeks. It's the lack of action that gets me, not that the problem reared it's head in the first place.

I don't want to rely on email at all but needs must. I'm also not one of the ones moaning about consumer protection either, I just wish things were sorted out

Dealing with communication in SL has it's own particular set of issues that you won't necessarily see elsewhere - they're just part and parcel of the parameters we have to operate within. How you'd want to it often isn't possible

Not to Jinx it or anything.... but it seems to be doing pretty good today.