Skip to content

Commit

Permalink
3.18.1 release notes
Browse files Browse the repository at this point in the history
  • Loading branch information
ppalaga committed Jan 30, 2025
1 parent eefb0d9 commit 38b453b
Show file tree
Hide file tree
Showing 3 changed files with 37 additions and 0 deletions.
1 change: 1 addition & 0 deletions docs/modules/ROOT/nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,7 @@
* xref:release-notes/index.adoc[Release notes]
ifeval::[{doc-is-main} == true]
** xref:release-notes/3.18.1.adoc[3.18.1]
** xref:release-notes/3.18.0.adoc[3.18.0]
** xref:release-notes/3.17.3.adoc[3.17.3]
** xref:release-notes/3.17.2.adoc[3.17.2]
Expand Down
35 changes: 35 additions & 0 deletions docs/modules/ROOT/pages/release-notes/3.18.1.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
= {quarkus-cxf-project-name} 3.18.0 release notes

== Important dependency upgrades

* Quarkus 3.18.0 -> 3.18.1 - https://quarkus.io/blog/quarkus-3-18-1-released/[release notes]


== Bugfixes

=== https://github.com/quarkiverse/quarkus-cxf/issues/1700[#1700] Pipe source resumed from wrong thread when passing response body from Vert.x HttpClient to CXF

In {quarkus-cxf-project-name} versions 3.18.0 (and possibly earlier), CXF clients based on Vert.x HTTP client froze sometimes,
especially when receiving larger requests.
The issue was caused by the fact that an internal class of Quarkus CXF, in an attempt to implement a standard Vert.x backpressure,
was resuming a Vert.x Pipe from a worker thread instead of Vert.x Event Loop.
That might sometimes have failed to awake the Pipe source from the paused state.
Due to that, the consuming thread would keep waiting for input forever.

Check https://github.com/quarkiverse/quarkus-cxf/issues/1700[#1700] for more details.

=== https://github.com/quarkiverse/quarkus-cxf/issues/1636[#1636] FastInfosetTest.fastInfoset fails intemittently

When using FastInfoset serialization format, the `InputStream` from which CXF is reading the service response,
is first closed by the deserialization layer,
but then, the HTTP layer tries to read all unconsumed data from it
and closes it once again.
`VertxHttpClientHTTPConduit` was not able to handle that sequence of operations properly.
After the first close, the subsequent read hanged sometimes waiting for more input,
when the producer was finished already.

Check https://github.com/quarkiverse/quarkus-cxf/issues/1636[#1636] for more details.

== Full changelog

https://github.com/quarkiverse/quarkus-cxf/compare/3.18.0+++...+++3.18.1
1 change: 1 addition & 0 deletions docs/modules/ROOT/pages/release-notes/index.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@ Those are typically released on Wednesday following the {quarkus-cxf-project-nam
|===
| Quarkus CXF | Release date | Quarkus Platform | CXF

| xref:release-notes/3.18.1.adoc[3.18.1] | 2024-01-30 | | 4.1.0
| xref:release-notes/3.18.0.adoc[3.18.0] | 2024-01-23 | 3.18.0 | 4.1.0

| xref:release-notes/3.17.3.adoc[3.17.3] | 2024-12-06 | 3.17.4 | 4.0.5
Expand Down

0 comments on commit 38b453b

Please sign in to comment.