I am using akka http websocket client and would like to keep the client alive.
On the section Automatic keep-alive Ping support it says, to put the configuration into application.conf as the following:
akka.http.client.websocket.periodic-keep-alive-mode = pong
I've done as:
akka.http {
websocket {
# periodic keep alive may be implemented using by sending Ping frames
# upon which the other side is expected to reply with a Pong frame,
# or by sending a Pong frame, which serves as unidirectional heartbeat.
# Valid values:
# ping - default, for bi-directional ping/pong keep-alive heartbeating
# pong - for uni-directional pong keep-alive heartbeating
#
# See https://tools.ietf.org/html/rfc6455#section-5.5.2
# and https://tools.ietf.org/html/rfc6455#section-5.5.3 for more information
periodic-keep-alive-mode = ping
# Interval for sending periodic keep-alives
# The frame sent will be the onne configured in akka.http.server.websocket.periodic-keep-alive-mode
# `infinite` by default, or a duration that is the max idle interval after which an keep-alive frame should be sent
periodic-keep-alive-max-idle = infinite
}
}
How to figure out, if the configuration was taken or not?
I'm not sure I really understand your question, but you can show the complete configuration (including overrides etc.) when the actor system is loaded by setting akka.log-config-on-start to on.
Akka Docs on Logging the Configuration
related stackoverflow
Related
we want to build a simple server component for ejabberd which receives all messages sent to MUC rooms (we have many rooms and new ones are being created all the time) and, after processing some of these messages, performs some operations.
We don't want our server component to act like a bot, so we don't want it to reply to messages or things like that, we just want it to receive copies of all messages in order to process some of them.
To do so, we have followed the tutorial available here: https://sleekxmpp.readthedocs.io/en/latest/getting_started/component.html
The problem is that the component seems to receive only some of the messages (approximately 1 out of 5).
Also, we are observing a weird behavior: message delivery seems to be "exclusive", meaning that a message is delivered either to clients connected to the room or to the server component, which is weird to be honest. In other words, 1 message out of 5 is delivered to the server component, and the other 4 are delivered to clients as usual.
Here's our component code (we have tried with both sleekxmpp and slixmpp but we always have the same behavior):
import sys
import logging
#import sleekxmpp
#from sleekxmpp.componentxmpp import ComponentXMPP
import slixmpp
from slixmpp.componentxmpp import ComponentXMPP
if sys.version_info < (3, 0):
from sleekxmpp.util.misc_ops import setdefaultencoding
setdefaultencoding('utf8')
else:
raw_input = input
class NotificationsComponent(ComponentXMPP):
def __init__(self):
ComponentXMPP.__init__(self, "muc.ourservice.it", "secret", "jabber.ourservice.it", 5233)
# add handler
self.add_event_handler("message", self.message)
#self.add_event_handler("groupchat_message", self.message)
def message(self, msg):
if msg['type'] == 'groupchat':
print('Received group chat message')
print(msg)
#msg.reply('Well received').send()
else:
print('Received another message')
if __name__ == '__main__':
logging.basicConfig(level=logging.DEBUG,format='%(levelname)-8s %(message)s')
xmpp = NotificationsComponent()
xmpp.register_plugin('xep_0030') # Service Discovery
#xmpp.register_plugin('xep_0004') # Data Forms
#xmpp.register_plugin('xep_0060') # PubSub
xmpp.register_plugin('xep_0199') # XMPP Ping
#xmpp.register_plugin('xep_0045') # MUC
# Connect to the XMPP server and start processing XMPP stanzas.
xmpp.connect()
xmpp.process()
and here's a snippet of our ejabberd 18.03 configuration:
listen:
-
port: 5222
ip: "::"
module: ejabberd_c2s
starttls: true
certfile: 'CERTFILE'
protocol_options: 'TLSOPTS'
## dhfile: 'DHFILE'
## ciphers: 'CIPHERS'
##
## To enforce TLS encryption for client connections,
## use this instead of the "starttls" option:
##
starttls_required: true
##
## Stream compression
##
zlib: true
##
max_stanza_size: 65536
shaper: none
access: c2s
-
port: 5280
ip: "::"
module: ejabberd_http
request_handlers:
"/admin": ejabberd_web_admin
"/bosh": mod_bosh
#request_handlers:
# "/ws": ejabberd_http_ws
# "/bosh": mod_bosh
# "/api": mod_http_api
## "/pub/archive": mod_http_fileserver
web_admin: true
http_bind: true
## register: true
captcha: false
certfile: 'CERTFILE'
tls: true
-
port: 5233
ip: "::"
module: ejabberd_service
access: all
privilege_access:
message: "outgoing"
password: "secret"
shaper: none
we have also tried to play with access, privilege_access and things like that but no luck.
Do you have any idea what might cause this weird behavior? Is there any particular plugin or module that should be enabled?
Of course, we have enabled debug logs on both sleekxmpp and ejabberd, but we don't see any errors, it's just that messages are missing.
We also did one more test. Even by using the official "echo component" example available in the slixmpp repository, we have the same issue. So it looks like there is some issue at our server, maybe on the message routing part, we don't know.
Thanks
I think you mixed a couple of things here. The component you created here seems to connect to ejabber as External Component (see https://xmpp.org/extensions/xep-0114.html or https://xmpp.org/extensions/xep-0225.html) judging from http://sleekxmpp.com/getting_started/component.html which means that ejabber (seems to at least) routes some messages to it's internal component and some to your (external) component. This would explain why your component receives only certain messages.
You have two options:
use SleekXMPP but connect as regular user (you can use "bot" example and simply listen for messages without responding)
create dedicated component/handler within ejabberd that would receive all messages and process them accordingly.
Both options has pros and cons:
client-in-room - easier (for you, it seems) development, but require to be constantly connected and may loose some messages if connection is dropped
dedicated handler in ejabberd - most likely slightly more difficult to implement.
It turns out I totally misunderstood the purpose of Jabber external components.
I was expecting to receive a "copy" of all events occurring within ejabberd, but I was wrong.
To achieve the result I was expecting, I'm using a module called "mod_post_log" which sends an HTTP request for every message sent by user. That works for me.
I went to the documentation and found out these
# The time after which an idle connection will be automatically closed.
# Set to infinite to completely disable idle connection timeouts.
idle-timeout = 10 s
# Defines the default time period within which the application has to
# produce an HttpResponse for any given HttpRequest it received.
# The timeout begins to run when the *end* of the request has been
# received, so even potentially long uploads can have a short timeout.
# Set to `infinite` to completely disable request timeout checking.
#
# If this setting is not `infinite` the HTTP server layer attaches a
# `Timeout-Access` header to the request, which enables programmatic
# customization of the timeout period and timeout response for each
# request individually.
request-timeout = 20 s
I have a scenario where my server takes more than 10 seconds to process a response but before sending the HTTPResponse the TCP connection between the client and server is timed out because of idle timeout.
Although the connection is idle at the moment but the request is still processing.
I thought this was the responsibility of response timeout?
Can anyone in this context explain me the difference between idle-timeout and response-timeout?
Documentation is a bit confusing, I have run the experiments based on that :
idle-timeout: It is the max time a connection can sit idle. It behaves the same as the Request timeout. Example :
idle-timeout = 1 s
Application has sent a request to 3rd party API and connection established, But 3rd party is not responding back. Then you will get a Timeout exception.
"akka.stream.scaladsl.TcpIdleTimeoutException"
connecting-timeout: 500 ms. It indicates the maximum time (500 ms) in which an Http connection must be established.
From the documentation and more details here
# The idle timeout for an open connection after which it will be closed
# Set to null or "infinite" to disable the timeout, but notice that this
# is not encouraged since timeout are important mechanisms to protect your
# servers from malicious attacks or programming mistakes.
idleTimeout = 75 seconds
If looks like you are setting the idle timeout lower than the request timeout, so it takes precedence. Your idle timeout settings should be longer than the request timeout, so for each request, the request timeout decides when to close the connection.
The spray-can docs comment on the spray.can.server.* and spray.can.client.* config settings:
spray.can.server {
# The time after which an idle connection will be automatically closed.
# Set to `infinite` to completely disable idle connection timeouts.
idle-timeout = 60 s
# If a request hasn't been responded to after the time period set here
# a `spray.http.Timedout` message will be sent to the timeout handler.
# Set to `infinite` to completely disable request timeouts.
request-timeout = 20 s
spray.can.client {
# The time after which an idle connection will be automatically closed.
# Set to `infinite` to completely disable idle timeouts.
idle-timeout = 60 s
# The max time period that a client connection will be waiting for a response
# before triggering a request timeout. The timer for this logic is not started
# until the connection is actually in a state to receive the response, which
# may be quite some time after the request has been received from the
# application!
# There are two main reasons to delay the start of the request timeout timer:
# 1. On the host-level API with pipelining disabled:
# If the request cannot be sent immediately because all connections are
# currently busy with earlier requests it has to be queued until a
# connection becomes available.
# 2. With pipelining enabled:
# The request timeout timer starts only once the response for the
# preceding request on the connection has arrived.
# Set to `infinite` to completely disable request timeouts.
request-timeout = 20 s
However, I also see that there's an implicit Timeout that can be passed to sendReceive.
Does setting any of the above config values result in a clash/override of the implicit Timeout? In short, I'm trying to understand the distinction between sendReceive's implicit time-out and the above config values.
Given:
client <-- HTTP --> spray web service <-- HTTP --> other web service
The client receives the following HTTP status code and entity body when hitting the spray web service:
504 Gateway Timeout - Empty
Per this answer, my understanding is that the spray web service is not receiving a timely response from the other web service, and thus sending an HTTP 504 to the client.
Assuming that's reasonable, per https://github.com/spray/spray/blob/master/spray-http/src/main/scala/spray/http/StatusCode.scala#L158, I'm guessing that one of these server config values is responsible for the 504 in the spray web service's HTTP response to the client.
What config or implicit would cause the spray web service to reply with a 504 to the client?
I think you are using the default Spray timeouts and perhaps you will need to increase them. If this is the case, there are 2 values you will have to configure to increase the timeouts.
idle-timeout: Time you can have an idle connection to your server before it is disconnected (default 60s).
request-timeout: Time a request from your client (from your server to another) can be idle before it timesout (default 20s).
The first value must be always higher than the second, as the idle-timeout will make pointless the connections from your request client.
So just overwrite your configuration in your application.conf like this:
spray.can {
server {
idle-timeout = 120 s
request-timeout = 20 s
}
}
In my src/main/resources/application.conf I include:
spray.can.server {
request-timeout = 1s
}
In order to test this, in the Future which is servicing my request I put a Thread.sleep(10000).
When I issue a request, the server waits 10 seconds and responds with no hint of a timeout being sent to the client.
I am not overriding the timeout handler.
Why are my clients (chrome and curl) not receiving a timeout?
The configuration looks correct, so Spray request timeout should be working. One of the frequent reasons for it not working is that your config application.conf is not being used by the application.
The reasons for config being ignored could be that it's in the wrong place, not included in your classpath, or not included in a JAR that you package.
To troubleshoot first check that default Spray timeout is working. By default it's 20 sec. Make your code sleep for 30sec and see if you get timeouts triggered.
Check what's in your final config values by printing it. Set this in your conf:
akka {
# Log the complete configuration at INFO level when the actor system is started.
# This is useful when you are uncertain of what configuration is used.
log-config-on-start = on
}
Finally, keep in mind other timeouts like timeout-timeout = 2 s.
I think the request-timeout is for the http client, if the response is not returned before that value, the client will get a timeout from spray, see the spary doc
# If a request hasn't been responded to after the time period set here
# a `spray.http.Timedout` message will be sent to the timeout handler.
# Set to `infinite` to completely disable request timeouts.
For example, in my web browser, I can got a below message:
Ooops! The server was not able to produce a timely response to your request.
Please try again in a short while!
If the timeout is long enough, the browser will keep waiting until a response is returned