karaf.log
[ODLPARENT-177] Modification of etc/org.ops4j.pax.web.cfg at runtime renders most of deployed servlets unusable Created: 27/Nov/18 Updated: 06/Feb/23 |
|
| Status: | Open |
| Project: | odlparent |
| Component/s: | Karaf |
| Affects Version/s: | 11.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Medium |
| Reporter: | Richard Kosegi | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | pick-next, pt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Fluorine-SR1 |
||
| Attachments: |
karaf.log
|
| Description |
|
Not sure if this project is right place to report this issue, so please move if necessary. Following procedure used to work until Fluorine:
Updating etc/org.ops4j.pax.web.cfg triggers reload of some pax-web bundles which results in existing servlets being undeployed:
opendaylight-user@root>http:list ID │ Servlet │ Servlet-Name │ State │ Alias │ Url ────┼────────────────────┼──────────────────────────────────┼─────────────┼─────────────────────┼──────────────────────────────────── 188 │ JolokiaServlet │ ServletModel-2 │ Undeployed │ /jolokia │ [/jolokia/*] 237 │ DiagStatusServlet │ ServletModel-5 │ Undeployed │ /diagstatus │ [/diagstatus/*] 304 │ ResourceServlet │ /apidoc/explorer:/explorer │ Undeployed │ /apidoc/explorer │ [/apidoc/explorer/*] 198 │ OAuth2TokenServlet │ ServletModel-10 │ Undeployed │ /oauth2 │ [/oauth2/*] 304 │ ServletContainer │ ServletContainer │ Undeployed │ │ [/apidoc/apis/*, /apidoc/18/apis/*] 198 │ MoonTokenEndpoint │ ServletModel-8 │ Undeployed │ /moon │ [/moon/*] 304 │ ResourceServlet │ /apidoc/18/explorer:/18/explorer │ Undeployed │ /apidoc/18/explorer │ [/apidoc/18/explorer/*] 188 │ JolokiaServlet │ ServletModel-38 │ Deployed │ /jolokia │ [/jolokia/*] opendaylight-user@root>
Now any restconf query will return HTTP404. |
| Comments |
| Comment by Tom Pantelis [ 27/Nov/18 ] |
|
This affects servlets across projects - seems like a general karaf/pax web issue so seems appropriate for odlparent. |
| Comment by Robert Varga [ 12/Mar/19 ] |
|
I suspect this is caused by blueprint being used to inject the servlets and the service going away, losing registrations and BP not restating |
| Comment by Robert Varga [ 01/Feb/23 ] |
|
rkosegi is this still repreducible? anmd if so, can you attach karaf.log? |
| Comment by Richard Kosegi [ 02/Feb/23 ] |
|
Hi Robert, I just tried with Chlorine-SR2 (0.17.2) and it's still reproducible using same steps. Karaf log is attached, modification of config file occurred at timestamp "2023-02-02T18:03:15,361". Then I hit apidocs at "2023-02-02T18:03:24,315" and got bunch of stacktraces in log |
| Comment by Robert Varga [ 06/Feb/23 ] |
|
The logs seem to indicate the /apidoc endpoint was refreshed and as such, it should not be affected by pax-web configuration: we are using HTTP Whiteboard, hence if pax-web is refreshed, it should just pick up our services from OSGi SR and re-publish them to whatever underlay. This does not seem to be the case, hence this needs a deeper analysis to determine whether we (odlparent/netconf) should do something differently, or if pax-web needs to fix something. As the exceptions are triggered when accessing the port, it feels like it is a pax-web problem – but we need the smoking gun... |