Project

General

Profile

amp component returns 404 remote-server-not-found

Igor Khomenko
Added almost 4 years ago

Hi there,

we face strange behaviour connected to amp component

Sometimes by some reason after user login (in about 1 min) we receive next presence

<presence xmlns="jabber:client" type="error" from="amp@app-chat-prod" to="2792282-92@chat.app.com/73B341DE-F8FC-4F81-9E53-6BC1B5856F19"><error type="cancel" code="404"><remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" lang="en">S2S - destination host not found</text></error></presence>

We don't use amp plugin at all, we just login to Tigase (7.0.1) and then wait

our init.properties:

config-type = --gen-config-all

# setup admins
--admins = 2509707-20756@chat.appio.com

# setup DBs
--user-db = mysql
--user-db-uri = ...

--data-repo-pool-size = 50

--auth-db = tigase.db.jdbc.IOAuth
--auth-db-uri = ...

# set domain
--virt-hosts = chat.appio.com
--ssl-def-cert-domain = chat.appio.com

# enable/disable plugins
--sm-plugins=-jabber:iq:private,-jabber:iq:register,-jabber:iq:auth,-jabber:iq:version,-msgoffline,-vcard-temp,+message-carbons


# enable MUC
--comp-name-2=muc
--comp-class-2=tigase.muc.MUCComponent
muc/message-filter-enabled[B]=false

# enable REST API
--comp-name-3=http
--comp-class-3=tigase.http.HttpMessageReceiver
http/http/server-class=tigase.http.jetty.JettyStandaloneHttpServer
http/rest/api-keys[s]=open_access
http/http/port[I]=8083


# enable WebSockets
ws2s/connections/ports[i]=5290,5291
ws2s/connections/5291/socket=ssl
ws2s/connections/5291/type=accept

# enable BOSH
bosh/connections/ports[i]=5280,5281
bosh/connections/5281/socket=ssl
bosh/connections/5281/type=accept

# enable XEP-0198
c2s/processors[s]=urn:xmpp:sm:3
c2s/processors/urn\:xmpp\:sm\:3/resumption-timeout[I]=60
c2s/processors/urn\:xmpp\:sm\:3/ack-request-count[I]=1

# enable monitoring
--monitoring = http:9080,jmx:9050

# setup logs
--debug = db,muc,xmpp
basic-conf/logging/tigase.db.level=WARNING
basic-conf/logging/tigase.muc.level=WARNING
basic-conf/logging/tigase.xmpp.level=WARNING

/etc/hosts contains the following:

127.0.0.1 localhost localhost.localdomain
10.279.29.223 app-chat-prod

where 10.279.29.223 is internal EC2 IP

hostname and hostname-f return app-chat-prod

As I understand, that presence sent MessageAmp plugin inside process method

but I don't understand why amp component returns sometimes 404 remote-server-not-found

Is there anything we have to check?


Replies (6)

Added by Wojciech Kapcia TigaseTeam almost 4 years ago

Igor Khomenko wrote:

We don't use amp plugin at all, we just login to Tigase (7.0.1) and then wait

Well, it's possible you do as it's the default plugin for handling <message/> stanzas

hostname and hostname-f return app-chat-prod

It's hard to tell why it's happening without full logs, but from the stanza you've shared:

<presence xmlns="jabber:client" type="error" from="amp@app-chat-prod" to="2792282-92@chat.app.com/73B341DE-F8FC-4F81-9E53-6BC1B5856F19"><error type="cancel" code="404"><remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" lang="en">S2S - destination host not found</text></error></presence>

It looks that you are using chat.app.com VHost and for some reason user 2792282-92@chat.app.com/73B341DE-F8FC-4F81-9E53-6BC1B5856F19 has sent to amp@app-chat-prod a presence. It's possible that amp@app-chat-prod was added to the roster and because of that, after logging in Tigase would generate presence broadcast.

Added by Igor Khomenko almost 4 years ago

Here is a code inside MessageAmp.process which as I understand sends this presence to amp component:

// notify AMP component that user is online now
if (packet.getStanzaTo() == null) {
    Packet notification = packet.copyElementOnly();
    notification.initVars(session.getJID(), ampJID);
    results.offer(notification);
}

But I don't understand why it returns an error then

Added by Igor Khomenko almost 4 years ago

I guess we ran again int this issue https://projects.tigase.org/boards/4/topics/4642 ...

logs were provided there

Still don't understand what should be done to avoid this

Do you have any ideas according to our settings above?

Added by Wojciech Kapcia TigaseTeam almost 4 years ago

Igor Khomenko wrote:

I guess we ran again int this issue https://projects.tigase.org/boards/4/topics/4642 ...

logs were provided there

Do you have any ideas according to our settings above?

full logs, short excerpt with the exception. There is no information about stanza that triggered the connection so it's difficult to identify the issue.

Best option would be to clear the logs, start the server, connect the client and wait for the exception and then share (archived) all logs.

Added by Igor Khomenko almost 4 years ago

I can see a lot of java.lang.Throwable logs just immediately after user login and it repeats every couple of seconds

and after some minutes after that I receive above error with amp

here is the 1st line of log, so it just comes:

2015-05-07 09:57:16.600 [in_4-message-router]  MessageRouter.processPacket()  FINEST:   Processing packet: from=amp@app-chat-prod, to=3-2@chat.app.com/iPhone6Plus, DATA=<presence from="amp@app-chat-prod" type="error" to="3-2@chat.app.com/iPhone6Plus" xmlns="jabber:client"><error code="404" type="cancel"><remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/><text xml:lang="en" xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">S2S - destination host not found</text></error></presence>, SIZE=365, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=error

We use configType=--gen-config-all

What I realised is when we changed it to configType=--gen-config-def then it works ok

Added by Wojciech Kapcia TigaseTeam almost 4 years ago

Igor Khomenko wrote:

I can see a lot of java.lang.Throwable logs just immediately after user login and it repeats every couple of seconds

and after some minutes after that I receive above error with amp

here is the 1st line of log, so it just comes:

This is still a single log line*, so it's hard to guess what's the reason… Again - please provide *complete log…

We use configType=--gen-config-all

What I realised is when we changed it to configType=--gen-config-def then it works ok

--gen-config-all enables more components, but should hardly cause such problem.

    (1-6/6)