| commit | 6eaa1d2f43612cddb2312e657455d0ef2bc5fd93 | [log] [tgz] |
|---|---|---|
| author | Sunitha Harish <sunithaharish04@gmail.com> | Fri Feb 19 13:38:31 2021 +0530 |
| committer | Ed Tanous <ed@tanous.net> | Thu Sep 30 18:02:43 2021 +0000 |
| tree | 11622ffb81396c3a87fcc18825bf0abd1bdc5652 | |
| parent | 1106333af4a5b566d8b3686b3438ddebc75b1b5d [diff] |
EventService : Fix retry handling for http-client
When the event send/receive is failed, the bmcweb does not handle
the failure to tear-down the complete connection and start a fresh
The keep-alive header from the event listener is read to update
the connection states, so that the connection will be kept alive
or closed as per the subscriber's specifications
Updated the connection state machine to handle retry logic properly.
Avoided multiple simultaneous async calls which crashes the bmcweb. So
added few "InProgress" flags which protects simultaneous async calls.
Changed buffer type from flat_buffer to flat_static_buffer and
imposed an upper limit on total size avoiding heap allocations.
Also changed the requestDataQueue from std::queue to
circular_buffer_space_optimized which allocates memory as needed
and dynamically controls size.
Used boost http response parser as parser for producing the response
message. Set the parser skip option to handle the empty response message
from listening server. On reception of response, the response code in
the header is checked to determine success/failure and trigger retry
in the case of failure.
Tested by:
- Subscribe for the events at BMC using DMTF event listener
- Generate an event and see the same is received at the listener's console
- Update the listner to change the keep-alive to true/false and
observe the http-client connection states at bmcweb
- Changed listener client to return non success HTTP status code
and observed retry logic gets trigrred in http-client.
- Gave wrong fqdn and observed async resolve failure and retry logc.
- Stopped listener after connect and verified timeouts on http-client
side.
Change-Id: Ibb45691f139916ba2954da37beda9d4f91c7cef3
Signed-off-by: Sunitha Harish <sunithaharish04@gmail.com>
Signed-off-by: AppaRao Puli <apparao.puli@linux.intel.com>
Signed-off-by: P Dheeraj Srujan Kumar <p.dheeraj.srujan.kumar@intel.com>
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D flags that correspond to options in bmcweb/meson_options.txt and then compiling. For example, meson <builddir> -Dkvm=disabled ... followed by ninja in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1 algorithm. The certificate
C=US, O=OpenBMC, CN=testhost,SHA-256 algorithm.