DISCO test fails (due to timeout?)

[lloydwatkin]

When testing for surevine.com's setup the channel server disco failed potentially due to a timeout (after checking the tests). It would be worth checking out why the test failed. Requests for me respond in 1 second using xmpp-ftw so it may not be the timeout.

[guilhermesgb]

This is a problem that can be observed happening with many other "long-duration" tests as well... they fail sometimes because Heroku will decide not to serve them (that's a guess) and respond with a H12 Request Timeout error. These tests usually start working again after a while. We maybe should deploy the protocol inspector in our own servers before v1.0.

I ran the buddycloud_disco test against surevine.com a couple times and it managed to succeed everytime here but I know that it fails sometimes, but I think the reason is 100% Heroku related.

[pniederlag]

I just observed the DISCO test failing, also my prosody instance seems to be setup properly. In the end I could only get the buddycloud_server_disco passing by adding a PTR record.
In order to find out about the miracles behind the disco discovery I found https://github.com/buddycloud/buddycloud-xep/blob/master/sections/30.discovery.xml which clearly points out how it works and pointed me to the solution with adding a PTR record

[imaginator]

@t3dev - we just had a call about this and, yes you can use a PTR record. But the DISCO stuff should be working and @guilhermesgb is looking at it.

[pniederlag]

I cloned the testing framework and tried to poke into it. Even raising the timeout to 30 seconds the disco discovery fails for me. I can't get any clou from the Exception as it seems to be empty. using xmpp-console in pidgin works nicely with:

<iq to="datenbetrieb.de" type="get" id="440a5251-e6fa-4b59-86a7-ed4e895a2ae5-1" from="inspect@buddycloud.org"><query xmlns="http://jabber.org/protocol/disco#items" /></iq>

Does disco need credentials or require a login to work?

[imaginator]

@guilhermesgb could it be something to do TLS security and the remote domain not having a valid certificate and therefore dropping the s2s connection?

Which domain do you test from? https://xmpp.net/result.php?domain=datenbetrieb.de&type=server

[guilhermesgb]

I really don't know. This test used to work as is (the disco, at least)...
at some point it stopped working but we failed to detect when and what
caused this.

[guilhermesgb]

The test connects to the xmpp-servers without SSL and TLS:

https://github.com/buddycloud/buddycloud-tests-framework/blob/master/installation/tests/buddycloud_server_disco.py#L146
xmpp.connect(conn_address, reattempt=False, use_ssl=False, use_tls=False)

Maybe this has something to do with it (secure connection is a must)?

On Tue, Apr 29, 2014 at 2:29 PM, Guilherme Santos guisgb13@gmail.comwrote:

I really don't know. This test used to work as is (the disco, at least)...
at some point it stopped working but we failed to detect when and what
caused this.

Guilherme Santos Galvão Baptista
UFCG Undergraduate Student - CS Major
UW-Madison Former Exchange Student - CS Major

[guilhermesgb]

I've read through the sleekxmpp source - it seems that if an SSL error
occurs, it is stopping the Send thread from sending our disco#items stanza:
https://github.com/fritzy/SleekXMPP/blob/d002d4c06fd90f5c6c0ddb38c0a38efc8fefd9ea/sleekxmpp/xmlstream/xmlstream.py#L1759
So I'm guessing that it indeed is a SSL-related problem...

On Tue, Apr 29, 2014 at 2:55 PM, Guilherme Santos guisgb13@gmail.comwrote:

The test connects to the xmpp-servers without SSL and TLS:

https://github.com/buddycloud/buddycloud-tests-framework/blob/master/installation/tests/buddycloud_server_disco.py#L146
xmpp.connect(conn_address, reattempt=False, use_ssl=False, use_tls=False)

Maybe this has something to do with it (secure connection is a must)?

On Tue, Apr 29, 2014 at 2:29 PM, Guilherme Santos guisgb13@gmail.comwrote:

I really don't know. This test used to work as is (the disco, at
least)... at some point it stopped working but we failed to detect when and
what caused this.

Guilherme Santos Galvão Baptista
UFCG Undergraduate Student - CS Major
UW-Madison Former Exchange Student - CS Major

Guilherme Santos Galvão Baptista
UFCG Undergraduate Student - CS Major
UW-Madison Former Exchange Student - CS Major

[pniederlag]

sleekXMPP ends with IqTimeout. On every attempt I find this in my prosody.log:

info incoming s2s stream (unknown host)->buddycloud.org closed: This host does not serve buddycloud.org

[guilhermesgb]

I've just finally fixed this test. Somehow this test used to work a few
months ago but I guess it was due to luck.
I've fixed this test following @abmargb 's take on performing disco
discovery with sleekxmpp, which I found
herehttps://github.com/buddycloud/hosting/blob/0bd8b4f7babaa1404911e29b17146a286fb6b5d2/hosting/xmppclient.py
.
After finding this I remembered him warning me about not doing things quite
correctly on that test, 'couple weeks ago.

By the way, @t3dev, I ran the protocol against datenbetrieb.de again and
just saw Service Discovery failing but now it seems the failure is
appropriate: apparently there's no XMPP Component whose identity is "of
category 'pubsub' and type 'channels'" (which is required, according
to thishttps://github.com/buddycloud/buddycloud-xep/blob/master/sections/30.discovery.xml)
defined (none of the components returned by disco#items presents this
identity when disco#info is performed).

On Wed, Apr 30, 2014 at 6:38 AM, Peter Niederlag
notifications@github.comwrote:

sleekXMPP ends with IqTimeout. On every attempt I find this in my
prosody.log:

info incoming s2s stream (unknown host)->buddycloud.org closed: This host
does not serve buddycloud.org

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-41778015
.

Guilherme Santos Galvão Baptista
UFCG Undergraduate Student - CS Major
UW-Madison Former Exchange Student - CS Major

[guilhermesgb]

On Wed, Apr 30, 2014 at 9:45 AM, Guilherme Santos guisgb13@gmail.comwrote:

datenbetrieb.de

Actually, I've payed more attention to the logs, what is happening when we
disco#info the buddycloud.datenbetrieb.de
http://buddycloud.datenbetrieb.de *component is this:
*DEBUG:sleekxmpp.xmlstream.xmlstream:RECV: Component
unavailable

I don't know what would cause this... @abmargb, any ideas?

Cheers,
Guilherme

Guilherme Santos Galvão Baptista
UFCG Undergraduate Student - CS Major
UW-Madison Former Exchange Student - CS Major

[abmargb]

Weird. Will take a look on this as soon as I have time.

On Wed, Apr 30, 2014 at 9:57 AM, Guilherme Santos
notifications@github.comwrote:

On Wed, Apr 30, 2014 at 9:45 AM, Guilherme Santos guisgb13@gmail.comwrote:

datenbetrieb.de

Actually, I've payed more attention to the logs, what is happening when we
disco#info the buddycloud.datenbetrieb.de
http://buddycloud.datenbetrieb.de *component is this:
*DEBUG:sleekxmpp.xmlstream.xmlstream:RECV: Component
unavailable

I don't know what would cause this... @abmargb, any ideas?

Cheers,
Guilherme

Guilherme Santos Galvão Baptista
UFCG Undergraduate Student - CS Major
UW-Madison Former Exchange Student - CS Major

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-41792967
.

Abmar Barros
MSc in Computer Science from the Federal University of Campina Grande -
www.ufcg.edu.br
OurGrid Team Leader - www.ourgrid.org
Buddycloud Dev - www.buddycloud.org
Paraíba - Brazil

[pniederlag]

awesome, thx. It works nicely now! @guilhermesgb I have been frequently debugging/restarting/changing the services and DNS so failures are likely.