Patrick, I'm trying to think how Jetty could treat the PUT request differently if it comes in two packets? Ultimately, unless you use specific APIs, the consumption of a request body is blocking, so your application should just block until the data arrives.
So what is throwing the NPE? Can you give us the full stack trace? How is you code consuming the request body? Request inputstream? Request reader? asynchronously? I assure you that jetty does correctly handle requests that are split into multiple packets (we even test sending them 1 byte per packet). So I expect there is some timing element happening with your application. regards On Sun, 21 Apr 2019 at 18:04, Patrick Dirks <[email protected]> wrote: > Alas, I spoke too soon; after merging in my change to the implementation > classes, it looks like now both Postman AND the cpp client stubs fail to > successfully pass an argument through the body of a PUT request. > > The client side hasn’t changed so I believe the PUT request is still > properly formatted. Interestingly, now both Postman (which sends the data > in a single packet) and the cpprest client (which sends the headers and the > body in separate packets) fail the same way, so there must be something > more subtle I’m just missing. At least I’m now on a supported build. > > FWIW, the stub generated for the function in question is > > public abstract Response twiddle(HostSpec body,SecurityContext > securityContext) throws NotFoundException; > > > but when it’s invoked ‘body’ is a null pointer (and previously, using > Postman, it would instead have the expected object format). > > Any suggestions for further tweaks or tests would be appreciated. Are > there means of externally enabling some logging of the Jetty internals? > > Thanks all the same, > -Patrick. > > On Apr 21, 2019, at 12:14 AM, Patrick Dirks <[email protected]> wrote: > > Hi Joakim, > > On Apr 20, 2019, at 9:36 PM, Joakim Erdfelt <[email protected]> wrote: > > 9.2.9 is rather old, even for the EOL 9.2.x series. > Consider using 9.2.28.v20190418. > Or if you want latest stable release, use 9.4.17.v20190418 > > > Yes, I just noticed on the Jetty web site that 9.2.x was, in fact, EOL. > I’m not sure how my system ended up with 9.2.9 installed - I believe that > was hard-wired in the generated SwaggerHub server stubs. > > I’m not sure what incompatibilities I should look out for upgrading to > 9.4.x. Offhand, just changing “jetty-version” in the generated pom.xml to > 9.4.17.v20190418 makes “man clean package jetty:run” yields a complaint > about the “.jar” format swagger-jaxrs-server that gets built not being > supported: > > [INFO] <<< jetty-maven-plugin:9.4.17.v20190418:run (default-cli) < > test-compile @ swagger-jaxrs-server <<< > [INFO] > [INFO] > > [INFO] --- jetty-maven-plugin:9.4.17.v20190418:run (default-cli) @ > swagger-jaxrs-server --- > [INFO] Logging initialized @6783ms to org.eclipse.jetty.util.log.Slf4jLog > [INFO] Skipping swagger-jaxrs-server : packaging type [jar] is unsupported > > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 5.980 s > [INFO] Finished at: 2019-04-20T23:57:41-07:00 > [INFO] ———————————————————————————————————— > > > which wasn’t exactly what I was hoping for :-) > > OTOH, looking back through the Jetty releases I tried the MUCH more > recent 9.3.26.v20190403 and THAT seems to suddenly work as expected! Looks > like this may have been an issue cleaned up since 9.2.9 hit the streets! > > I think I’m good with 9.3.26.v20190403! I’ll test some other client stubs > and see if this actually completely resolved the problem but it certainly > appears to have fixes this issue. > > Thanks for the tip! > > Regards, > -Patrick. > > > Joakim Erdfelt / [email protected] > > > On Sat, Apr 20, 2019 at 7:13 PM Patrick Dirks <[email protected]> wrote: > >> Hi, >> >> I’m new to Jetty - I'm experimenting with an API on SwaggerHub and I've >> generated both client-side (cpprest) and server-side (JAX-RS) stubs from >> the API. My server side is running jetty-9.2.9.v20150224. >> >> When I use a client like Postman, which sends the complete request >> (headers and body) in a single packet, the server responds as expected. >> When I use the generated (cpprest) client stubs the request headers come in >> a first packet and the body in a second packet. The strange part is that, >> although they re-assemble fine (I can see a valid-looking combined packet >> in Wireshark), it looks as if the server request is dispatched as soon as >> the headers arrive, without waiting for the body parameters to arrive >> (despite the "Content-length" header value)? >> >> As a result the server sees a request that's got a "null" value for the >> body parameter (even though the parameter is marked as "required"), as if >> "delayDispatchUntilContent" is false? I've tried adding a "jetty.xml" file >> that explicitly defaults and sets "delayDispatchUntilContent" to "true" but >> that doesn't seem to make any difference. Neither does Swagger 2.0 vs. >> OpenAPI 3.0 use make any difference. >> >> Any idea what I'm missing here? Any suggestions for a workaround, or a >> fix? >> >> Thanks in advance! >> -Patrick. >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7Cd7e8c1f84c544912073708d6c628faff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914276649449493&sdata=9%2Bh9n8%2Bu2E8z8mTkEjE2J%2FMeiheo%2BJIkMGkZzL4UB7s%3D&reserved=0> > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7Ca7c9e4fef0184cdafd5708d6c612e60f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914181845701630&sdata=WxC5KN6%2B1I%2FvPWV001JcByKQ5DrV7PhcHcP5QeVrpOc%3D&reserved=0 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7Cd7e8c1f84c544912073708d6c628faff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914276649459498&sdata=VhJrdp7rMLgdgatYgRq1KuGMK5IzcYlh%2B%2Fzd%2F%2B%2Bt5Ps%3D&reserved=0> > > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fjetty-users&data=02%7C01%7Cpdirks%40vmware.com%7Cd7e8c1f84c544912073708d6c628faff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636914276649469507&sdata=Qq7UxXMTwIsmIe6ZLYUjeXJpduR9rJEc4XCdqttuP04%3D&reserved=0 > > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins <[email protected]> CTO http://webtide.com
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
