In CoverArtController and StreamController, AsyncRequestNotUsableException will be changed to be output to TRACE.
If you've ever used Subsonic or Airsonic, you've probably seen log files that look like that spell. In Jpsonic, the contents output to the log file are organized to some extent. What I have seen relatively often on legacy servers is errors related to Close from the client while outputting a response. (When viewed from the server, it is expressed as ``I tried to write, but I can't write!''.) This will probably happen relatively often when streaming music. Usually these are suppressed.
In Jpsonic, these exceptions that often occur during writing image or streaming are logged at the TRACE level. However, the exception design especially related to communication has been frequently changed in Apps Servers or Frame Work. The issues covered in this issue are to follow changes in Spring's exception specifications.
Goal
This will now be fixed to prevent redundant logs from being output as before.
A recent update to Spring Boot (3.2.4) provides enhanced protection against concurrent error handling for asynchronous requests.
Also confirmed by Jpsonic. This log will be modified to be output to TRACE again.
Non-Goal
No changes are made to the design or code for catching exceptions. It just adds more types of exceptions to be caught (to TRACE).
Details
For simple Apps, it would be possible to standardize exception handling using DefaultHandlerExceptionResolver etc. However, servers directly related to Subsonic handle various protocols at the same time. Web pages, APIs, UPnP, etc. each have their own methods for notifying exceptions.
An exception (derived from IOException) due to a unilateral close by the Client may occur anywhere. However, according to our experience, this occurs most often when outputting images and streaming. (We may not see much else) Therefore, CoverArtController and StreamController have code to explicitly trace this exception. These judgment processes are shared by LoggingExceptionResolver.
The classes to be traced are as follows. (Also, please note that the IOException is not caught, but rather a specific class is specified for determination.)
Managed by these class name strings. This is because Jpsonic supports Tomcat/Jetty compile. It shows that the exception that was previously thrown by the 3rd-pirty exception class is now wrapped by AsyncRequestNotUsableException.
Of course, I would like to add that there may be more elegant ways to write it. However, the specification changes regarding ClientAbort have changed more than once or twice. (Simplicity that avoids complex architects and ease of investigation may be important!) A flurry of improvements related to synchronous and asynchronous communication are currently happening simultaneously in Tomcat/Jetty/Spring.
Overview
In CoverArtController and StreamController, AsyncRequestNotUsableException will be changed to be output to TRACE.
If you've ever used Subsonic or Airsonic, you've probably seen log files that look like that spell. In Jpsonic, the contents output to the log file are organized to some extent. What I have seen relatively often on legacy servers is errors related to Close from the client while outputting a response. (When viewed from the server, it is expressed as ``I tried to write, but I can't write!''.) This will probably happen relatively often when streaming music. Usually these are suppressed.
In Jpsonic, these exceptions that often occur during writing image or streaming are logged at the TRACE level. However, the exception design especially related to communication has been frequently changed in Apps Servers or Frame Work. The issues covered in this issue are to follow changes in Spring's exception specifications.
Goal
This will now be fixed to prevent redundant logs from being output as before.
A recent update to Spring Boot (3.2.4) provides enhanced protection against concurrent error handling for asynchronous requests.
ttps://github.com/spring-projects/spring-framework/issues/32340This side effect caused verbose logs related to AsyncRequestNotUsableException to be output.
ttps://github.com/spring-projects/spring-framework/issues/32509Also confirmed by Jpsonic. This log will be modified to be output to TRACE again.
Non-Goal
No changes are made to the design or code for catching exceptions. It just adds more types of exceptions to be caught (to TRACE).
Details
For simple Apps, it would be possible to standardize exception handling using DefaultHandlerExceptionResolver etc. However, servers directly related to Subsonic handle various protocols at the same time. Web pages, APIs, UPnP, etc. each have their own methods for notifying exceptions.
An exception (derived from IOException) due to a unilateral close by the Client may occur anywhere. However, according to our experience, this occurs most often when outputting images and streaming. (We may not see much else) Therefore, CoverArtController and StreamController have code to explicitly trace this exception. These judgment processes are shared by LoggingExceptionResolver.
The classes to be traced are as follows. (Also, please note that the IOException is not caught, but rather a specific class is specified for determination.)
Managed by these class name strings. This is because Jpsonic supports Tomcat/Jetty compile. It shows that the exception that was previously thrown by the 3rd-pirty exception class is now wrapped by AsyncRequestNotUsableException.
Of course, I would like to add that there may be more elegant ways to write it. However, the specification changes regarding ClientAbort have changed more than once or twice. (Simplicity that avoids complex architects and ease of investigation may be important!) A flurry of improvements related to synchronous and asynchronous communication are currently happening simultaneously in Tomcat/Jetty/Spring.