John
See the tcp section of the configuration,
1. tcp {
2.
3. # The number of selectors to stripe the served channels over; each of
4. # these will use one select loop on the selector-dispatcher.
5. nr-of-selectors = 1
6.
7. # Maximum number of open channels supported by this TCP module; there
is
8. # no intrinsic general limit, this setting is meant to enable DoS
9. # protection by limiting the number of concurrently connected clients.
10. # Also note that this is a "soft" limit; in certain cases the
implementation
11. # will accept a few connections more or a few less than the number
configured
12. # here. Must be an integer > 0 or "unlimited".
13. max-channels = 256000
14.
15. # When trying to assign a new connection to a selector and the chosen
16. # selector is at full capacity, retry selector choosing and
assignment
17. # this many times before giving up
18. selector-association-retries = 10
19.
20. # The maximum number of connection that are accepted in one go,
21. # higher numbers decrease latency, lower numbers increase fairness on
22. # the worker-dispatcher
23. batch-accept-limit = 10
24.
25. # The number of bytes per direct buffer in the pool used to read or
write
26. # network data from the kernel.
27. direct-buffer-size = 128 KiB
28.
29. # The maximal number of direct buffers kept in the direct buffer
pool for
30. # reuse.
31. direct-buffer-pool-limit = 1000
32.
33. # The duration a connection actor waits for a `Register` message from
34. # its commander before aborting the connection.
35. register-timeout = 5s
36.
37. # The maximum number of bytes delivered by a `Received` message.
Before
38. # more data is read from the network the connection actor will try to
39. # do other work.
40. # The purpose of this setting is to impose a smaller limit than the
41. # configured receive buffer size. When using value 'unlimited' it
will
42. # try to read all from the receive buffer.
43. max-received-message-size = unlimited
44.
45. # Enable fine grained logging of what goes on inside the
implementation.
46. # Be aware that this may log more than once per message sent to the
actors
47. # of the tcp implementation.
48. trace-logging = off
49.
50. # Fully qualified config path which holds the dispatcher
configuration
51. # to be used for running the select() calls in the selectors
52. selector-dispatcher = "akka.io.pinned-dispatcher"
53.
54. # Fully qualified config path which holds the dispatcher
configuration
55. # for the read/write worker actors
56. worker-dispatcher = "akka.actor.default-dispatcher"
57.
58. # Fully qualified config path which holds the dispatcher
configuration
59. # for the selector management actors
60. management-dispatcher = "akka.actor.default-dispatcher"
61.
62. # Fully qualified config path which holds the dispatcher
configuration
63. # on which file IO tasks are scheduled
64. file-io-dispatcher = "akka.actor.default-dispatcher"
65.
66. # The maximum number of bytes (or "unlimited") to transfer in one
batch
67. # when using `WriteFile` command which uses `FileChannel.transferTo`
to
68. # pipe files to a TCP socket. On some OS like Linux
`FileChannel.transferTo`
69. # may block for a long time when network IO is faster than file IO.
70. # Decreasing the value may improve fairness while increasing may
improve
71. # throughput.
72. file-io-transferTo-limit = 512 KiB
73.
74. # The number of times to retry the `finishConnect` call after being
notified about
75. # OP_CONNECT. Retries are needed if the OP_CONNECT notification
doesn't imply that
76. # `finishConnect` will succeed, which is the case on Android.
77. finish-connect-retries = 5
78.
79. # On Windows connection aborts are not reliably detected unless an
OP_READ is
80. # registered on the selector _after_ the connection has been reset.
This
81. # workaround enables an OP_CONNECT which forces the abort to be
visible on Windows.
82. # Enabling this setting on other platforms than Windows will cause
various failures
83. # and undefined behavior.
84. # Possible values of this key are on, off and auto where auto will
enable the
85. # workaround if Windows is detected automatically.
86. windows-connection-abort-workaround-enabled = off
87. }
On Mon, Jul 13, 2015 at 9:25 PM, <[email protected]> wrote:
> I am using basically the java client from
> http://doc.akka.io/docs/akka/2.3.12/java/io-tcp.html (public class Client
> extends UntypedActor)
> to integrate to an akka tcp backend on another machine.
>
> Since the client is also a server it will be creating many short-lived
> tcp client outgoing connections.
> like:
> 127.0.0.1:5695 -> backend:99
> 127.0.0.1:5696 -> backend:99
> ....
> 127.0.0.1:7696 -> backend:99
>
> I am a little worried that I may have problems with port exhaustion .
> The code is running on a Linux box.
>
> Does somebody have a similar setup in production? What are you experiences
> so far?
>
>
>
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
Cheers,
√
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
