Notify.io API down again?

3 views
Skip to first unread message

saqeb.akhter

unread,
Sep 18, 2010, 12:56:54 PM9/18/10
to Notify.io
Looks like the API is down again, can't send notifications......we
really need some reliability in this space.

saqeb.akhter

unread,
Sep 18, 2010, 1:15:56 PM9/18/10
to Notify.io
What would need to be done to make this more reliable ? Pherhaps I
could help...

Jeff Lindsay

unread,
Sep 18, 2010, 1:59:32 PM9/18/10
to noti...@googlegroups.com
Fixed. Here is what needs to be done to get it 100% reliable (ignoring App Engine or Twilio Realtime outages): Help refactor the code to drop the dependency on api/server.py -- for example, instead of pushing to Realtime from api/server.py, do it from the app engine app. Then (or before) we need to update the links for new users from the old client download link that doesn't support Realtime (or can redirect to Realtime). Then we have to add redirects to api/server.py for old users using old Listen URLs. Lastly, modify api/server.py to detect the old client and bother people to upgrade. 

In theory, we could ignore the upgrade path for the old client since there aren't *that* many users that aren't on this list (I don't think). 

-jeff
--
Jeff Lindsay
http://progrium.com

Jeff Lindsay

unread,
Sep 18, 2010, 3:04:04 PM9/18/10
to saqeb....@gmail.com, noti...@googlegroups.com
Cool. Just go to http://code.google.com/appengine/ and grab the SDK for Python and check out the docs.. App Engine just provides some APIs to services like storage etc that Notify.io uses. 

Unfortunately, the app isn't documented (or tested!! *sadface*), but the code is on GitHub. Currently, the flow for a notification is:

Request to api.notify.io goes to api/server.py which hands the notification off (via HTTP) to the App Engine app to figure out routing and send it where it needs to go. If it's routed to the desktop notifier, it will give a response that tells api/server.py which listen URLs should get the notification (since the listen urls point to api/server.py). 

The problem is api/server.py and the host it's on will run out of available connections from all the listeners. Although this could be hacked with or moved somewhere else, it will always be a bottleneck eventually. So now we use a messaging server in the cloud for listening. You can see that api/server.py has been modified to also post all notifications into the new messaging server. If we can make that happen on App Engine, we're one step closer to eliminating api/server.py and never dealing with this problem again.

-jeff

On Sat, Sep 18, 2010 at 11:35 AM, <saqeb....@gmail.com> wrote:
Not to much, but I'm pretty comfortable with programming so it shouldn't be that hard to pick up.


On Sep 18, 2010 2:31pm, Jeff Lindsay <prog...@gmail.com> wrote:
> Are you familiar with App Engine?
>
> On Sat, Sep 18, 2010 at 11:23 AM, saqeb.akhter saqeb....@gmail.com> wrote:
>
> Could you point me to some documentation on the app engine app?

Brian Dunnington

unread,
Sep 21, 2010, 2:06:54 PM9/21/10
to noti...@googlegroups.com
On Sat, Sep 18, 2010 at 10:59 AM, Jeff Lindsay <prog...@gmail.com> wrote:
> In theory, we could ignore the upgrade path for the old client since there
> aren't *that* many users that aren't on this list (I don't think).
> -jeff

when you made the change to the listen urls to use outlets, that was a
breaking change for existing clients and at the time you said:

"Unless there's a huge backlash, I'm not going to worry about
backwards compatibility since it's "pre-alpha". "

it was a pain to update my client (Growl for Windows addin) and make
sure all users updated since you had previously confirmed that the
urls and json structure were set, but i understood the rational. right
now, the risk is that if you make the changes, users of old versions
of Nio will be broken. but the alternative is that notify.io keeps
going down and is thus 'broken' for everyone. it would be better to
fix it for most users and those that need to update will have
incentive.

just my 2 cents.

Jeff Lindsay

unread,
Sep 21, 2010, 3:52:00 PM9/21/10
to noti...@googlegroups.com
Thanks. Let me see if I can make some progress in that direction today.

David

unread,
Sep 23, 2010, 5:53:52 AM9/23/10
to Notify.io
Down Again I think

On Sep 21, 8:52 pm, Jeff Lindsay <progr...@gmail.com> wrote:
> Thanks. Let me see if I can make some progress in that direction today.
>
> On Tue, Sep 21, 2010 at 11:06 AM, Brian Dunnington <
>
>
>
> briandunning...@gmail.com> wrote:

Jeff Lindsay

unread,
Sep 23, 2010, 11:08:16 AM9/23/10
to noti...@googlegroups.com
Crazy. Usage is going up, so it's failing faster. Restarted for now
but I just got an idea to make the switch go faster. I'll try that
tonight.

--
Jeff Lindsay
http://progrium.com

saqeb.akhter

unread,
Sep 24, 2010, 11:28:05 AM9/24/10
to Notify.io
Anyway to see which Source is making the usage go up?

I'm curious to know.

saqeb.akhter

unread,
Sep 24, 2010, 11:32:12 AM9/24/10
to Notify.io
Also I think what you mentioned before is probably the way to go i.e)
Moving the entire API to RealTime/AppEngine to avoid having this issue
altogether.

On Sep 23, 11:08 am, Jeff Lindsay <progr...@gmail.com> wrote:

Jeff Lindsay

unread,
Sep 24, 2010, 12:09:09 PM9/24/10
to noti...@googlegroups.com
Sources aren't the problem, it's number of listeners (people using Desktop Notifier).
Reply all
Reply to author
Forward
0 new messages