This message was deleted.

With a smaller file the transition from Jetty to wiremock is visible in the logs:

2023-01-27 11:55:29,029 [qtp1749988512-59] DEBUG org.eclipse.jetty.server.HttpInput - read at EOF, setting consumed EOF to true HttpInput@28980600 cs=HttpChannelState@77a6c2d3{s=HANDLING rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0} cp=org.eclipse.jetty.server.BlockingContentProducer@46fb79e eof=false mdc={}
2023-01-27 11:55:29,029 [qtp1749988512-59] DEBUG org.eclipse.jetty.server.BlockingContentProducer - onContentProducible releasing semaphore LockedSemaphore permits=0 unready=false mdc={}
2023-01-27 11:55:29,064 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - About to parse: inline@0 mdc={}
2023-01-27 11:55:29,121 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - Building AST mdc={}
2023-01-27 11:55:29,129 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - Creating templates mdc={}
2023-01-27 11:55:29,147 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - About to parse: inline@46496399 mdc={}
2023-01-27 11:55:29,147 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - Building AST mdc={}
2023-01-27 11:55:29,157 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - Creating templates mdc={}
2023-01-27 11:55:29,179 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - About to parse: inline@0 mdc={}
2023-01-27 11:55:29,179 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - Building AST mdc={}
2023-01-27 11:55:29,179 [qtp1749988512-59] DEBUG com.github.jknack.handlebars.internal.HbsParserFactory - Creating templates mdc={}
2023-01-27 11:55:29.181 Request received:
127.0.0.1 - POST /secure-messages-api/v1/attachments

for larger files there's nothing past these log statements which are also present above:

2023-01-27 12:01:44,424 [qtp1749988512-60] DEBUG org.eclipse.jetty.server.HttpInput - read at EOF, setting consumed EOF to true HttpInput@2044199160 cs=HttpChannelState@152245c9{s=HANDLING rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0} cp=org.eclipse.jetty.server.BlockingContentProducer@27c54f7 eof=false mdc={}
2023-01-27 12:01:44,424 [qtp1749988512-60] DEBUG org.eclipse.jetty.server.BlockingContentProducer - onContentProducible releasing semaphore LockedSemaphore permits=0 unready=false mdc={}

Thanks for reporting this @Jon Wilmoth. Would you mind sharing the WireMock startup parameters you’re using. Also just to confirm - when you say it hangs on the larger file, you mean the request never receives a response (and eventually times out on the client)?

@Tom Correct, no response and client eventually times out. Here's the WireMock config:

WireMockConfiguration options =
        options()
            .port(8089)
            .notifier(new ConsoleNotifier(true))
            .usingFilesUnderClasspath(getMappingRoot())
            .extensions(new ResponseTemplateTransformer(false));

Since this seems like a potential regression (maybe related to the underlying Jetty upgrade) I opened https://github.com/wiremock/wiremock/issues/2072 and have added the WireMockConfiguration / server startup details there as well.

I agree this sounds like a regression. WireMock has generally been slower since moving to Jetty 11 and I’m still trying to figure out why. So, thanks for raising the GH issue - I’ll continue posting on there as/when I find a fix.