Hi Rusty,

On Mon, Nov 26, 2012 at 4:58 PM, rusty <[email protected]> wrote:

> As part of a proof-of-concept, we are trying to set up an
> eat-your-own-dog-food sort of scenario in which we can publish Google
> Public Alerts to a hub (for testing purposes, we're just using
> http://pubsubhubbub.appspot.com/) and then subscribe to and be notified
> by that hub as well. We had some initial problems getting subscriptions to
> verify, but we have confirmed that we are indeed subscribed to the hub at
> this point. The problem is, it appears that we are getting a response of
> 204 back whenever we publish an alert to said hub, but our callback URL is
> not being sent any notifications whatsoever.
>
> We have enough logging enabled that we would know if a notification had at
> least hit the URL at all, and nothing is arriving to us from the hub. We
> know the callback URL is not an issue, though, because it at least appears
> that we were able to get our subscription verified. The same callback URL
> handles subscriptions and notifications.
>
> Fearing we had done something wrong somewhere, we set up an open-source
> hub (Wolverine, for those interested) and tested our publishing /
> subscribing code on that. We were able to subscribe to the Wolverine hub,
> and upon publishing to it, our notification callback URL was hit with a
> notification. This worked flawlessly, so I know at this point that our code
> is at least good enough for Wolverine.
>
> What could we possibly be missing at this point?
>
> Here are a few more pointed questions:
> 1. What in particular would make the PSHS hub refuse to send notifications
> to a callback URL?


If a subscription is active, the hub will refuse to send updates if there
are too many fetch errors from the domain. You aren't hitting the limit,
though.


> Is it possible to find out where our notifications are going? Is it
> possible to find out if the hub really has accepted our published updates?
> We have used both the Publisher PHP client library as well as the PSHS
> publish link, and neither results in any updates being pushed to our
> callback URL. We know that the hub is able to reach the callback URL with
> the subscription confirmation request, ruling out firewall issues.
>

If you could send me topic URL and callback URL (privately if you want),
I'll take a look.

2. Some of our subscription details (callback URL omitted for privacy
> reasons) include:
> State:     verified
> Confirmation failures:     3
> Delivery to domain:     OK
> Delivery short-term:     0% errors
>
> What does "confirmation failures: 3" mean?


It means subscription verification has failed 3 times in a row (that's
maximum) since the last subscription request was received. Apparently, the
subscription had already been verified when the last subscription request
was received.

Does delivery to domain mean what I think it means, i.e. the hub at least
> thinks it is pushing notifications to our callback URL?
>

It means your are not being throttled. It doesn't mean anything is being
sent to your domain.

Roman.

Reply via email to