Age | Commit message (Collapse) | Author |
|
|
|
|
|
* anders/diameter/21.0/OTP-15110:
Make diameter_app_SUITE fail more usefully
Simplify app-file generation
Match in diameter_app_SUITE to identify an unexpected path
Don't use deprecated ssl:ssl_accept/1-3
Don't use deprecated erlang:get_stacktrace/0
|
|
The badmatch in the grandparent commit is ssl not being installed:
=== Reason: no match of right hand side value {ssl,non_existing,
["non_existing"]}
in function diameter_app_SUITE:app/1 (diameter_app_SUITE.erl, line 266)
in call from diameter_app_SUITE:'-xref/1-fun-3-'/2 (diameter_app_SUITE.erl, line 214)
in call from lists:'-filter/2-lc$^0/1-0-'/2 (lists.erl, line 1286)
in call from diameter_app_SUITE:xref/1 (diameter_app_SUITE.erl, line 214)
in call from test_server:ts_tc/3 (test_server.erl, line 1545)
in call from test_server:run_test_case_eval1/6 (test_server.erl, line 1063)
in call from test_server:run_test_case_eval/9 (test_server.erl, line 995)
Tweak the failure a bit more, without fixing it.
|
|
Don't bother generating applications/runtime_dependencies: what's lost
in duplication is gained in clarity.
SSL in runtime_applications but not applications in questionable, but
it's been this way for a long time with no apparent ill effects or
protests.
|
|
See this failure in nightly test on one host, indicating that
code:which/1 is returning something other than the expected path:
=== Ended at 2018-06-08 05:10:41
=== Location: [{lists,nth,170},
{diameter_app_SUITE,app,265},
{diameter_app_SUITE,'-xref/1-fun-3-',214},
{lists,'-filter/2-lc$^0/1-0-',1286},
{diameter_app_SUITE,xref,214},
{test_server,ts_tc,1545},
{test_server,run_test_case_eval1,1063},
{test_server,run_test_case_eval,995}]
=== Reason: no function clause matching lists:nth(2,[]) (lists.erl, line 170)
in function diameter_app_SUITE:app/1 (diameter_app_SUITE.erl, line 265)
in call from diameter_app_SUITE:'-xref/1-fun-3-'/2 (diameter_app_SUITE.erl, line 214)
in call from lists:'-filter/2-lc$^0/1-0-'/2 (lists.erl, line 1286)
in call from diameter_app_SUITE:xref/1 (diameter_app_SUITE.erl, line 214)
in call from test_server:ts_tc/3 (test_server.erl, line 1545)
in call from test_server:run_test_case_eval1/6 (test_server.erl, line 1063)
in call from test_server:run_test_case_eval/9 (test_server.erl, line 995)
|
|
|
|
|
|
This reverts commit fd8e49b5bddceaae803670121b603b5eee8c5c08.
|
|
|
|
This reverts commit 202bb737e3deabfebee683266f4b7c42781eb521.
|
|
|
|
|
|
|
|
For a documentation typo.
|
|
|
|
|
|
* anders/diameter/20.3/OTP-14946:
vsn -> 2.1.4
Update appup for 20.3
Update service_info examples in doc
Fix inaccurate comment
|
|
* anders/diameter/terminate/ERIERL-124:
Fix handling of SUSPECT connections at service termination
|
|
* anders/diameter/reg/OTP-14839:
Fix diameter_reg:subscribe/2 remove notification
|
|
|
|
|
|
Timestamps have been monotonic time since OTP-17.5. See commit e6d19a18.
The examples should really be replaced by more detailed doc of return
values.
|
|
A peer_fsm process can be started long before a connection is
established in the listening case. The time reported in a 'peer' tuple
in service_info is of connection establishment.
|
|
A peer connection in watchdog state SUSPECT is represented by a peer
table entry in diameter_service, but not by a request table entry in
diameter_peer, so diameter_service:terminate/2 could result in failures
like this:
exception error: no match of right hand side value []
in function diameter_traffic:peer_down/1 (base/diameter_traffic.erl, line 141)
in call from lists:foldl/3 (lists.erl, line 1263)
in call from ets:do_foldl/4 (ets.erl, line 611)
in call from ets:foldl/3 (ets.erl, line 600)
in call from diameter_service:terminate/2 (base/diameter_service.erl, line 557)
in call from gen_server:try_terminate/3 (gen_server.erl, line 648)
in call from gen_server:terminate/10 (gen_server.erl, line 833)
in call from gen_server:handle_msg/6 (gen_server.erl, line 679)
|
|
Commit fae8ca0c broke notification by removing table elements before
matching for them, causing diameter_tcp/sctp listening processes to
live on after diameter:remove_transport/2.
Commit 58091992 added diameter_reg:subscribe/2, and commit 5ca5fb71
started using it for listener exit.
|
|
|
|
|
|
Only change is doc.
|
|
|
|
|
|
* anders/diameter/decode/OTP-14684:
vsn -> 2.1.2
Update appup for ERIERL-14684
|
|
The options map wasn't updated after the AVP was identified, with
the resulting consequences for M-bit interpretation.
|
|
Which may have been used in the past, but aren't now.
|
|
The wrong variable was passed into the decode recursion, causing the
options map to be contaminated by strict_mbit and failed_avp
modifications that should only apply to component AVPs in the Grouped
case. Decode errors and M-bits could be ignored as a result.
|
|
|
|
|
|
|
|
|
|
|
|
Commit fae8ca0c inadvertently removed the monitor at add/1 and
add_new/1. As a result, process death did not remove associations,
causing table diameter_reg to leak entries and stop/start of a service
to fail.
Add a testcase to detect the problem, which existing testcases miss.
|
|
|
|
* anders/diameter/doc/OTP-14561:
Document new(ish) options in diameter_tcp/sctp
|
|
* anders/diameter/SoC/OTP-10927:
Simplify/complete Standards Compliance doc
|
|
With a table. Probably no one wants to read a commented RFC, it's been
unfinished for some time, and it's difficult to get an overview from it.
|
|
See commits d3829525 (unordered), c591056b (packet), eadf4efc (sender),
636a7199 (tcp message_cb), 373cd07c (sctp message_cb)
|
|
* anders/diameter/20.1/OTP-14561:
Update appup and version for 20.1
|
|
* anders/diameter/sctp/OTP-10889:
Make unordered delivery configurable
|
|
* anders/diameter/performance/OTP-14521:
Fix append of Route-Record AVPs
|
|
Changing the default in the parent commit is possibly a bit dangerous,
even if the motivation still holds. Take a step back and make unordered
delivery a matter of configuration, without changing the default:
configuration is {unordered, boolean() | pos_integer()}, with false the
default, and N equivalent to OS =< N, where OS is the number of outbound
streams negotiated on the association in question.
A user can mess with this by configuring an sctp_default_send_param of
their own, but unordered sending is them from start, not only after the
second message reception.
|