Hello.! I think that I've found an explanation of this behavior that is probably not a bug.
Our code that fails because of the unreadable content is called by an ExchangeSentEvent handler. After debugging this code, setting a breakpoint on the StreamCache reset method, I see that the stream is reset later by a "StreamCachingAdice.after" operation, and not just after the endpoint (file) has produced its output. This explains why during my event handler the cached content seems to be unreadable. In my case, calling reset on the StreamCache instance seems to fix the issue. I hope this can help someone else... Regards. Le ven. 17 nov. 2023 à 16:29, Ephemeris Lappis <ephemeris.lap...@gmail.com> a écrit : > > Hello. > > We've some kind of random behavior on routes that use stream caching, > with the default configuration. All our routes are executed using > blueprints in Karaf. The same error happens on old Camel 2.x on Fuse > and Camel 3.21.x on Karaf 4.x. > > In some cases the previous body is the result of a JAXB marshalling. > Some other cases use other data formats (BeanIO for example). Anyway, > the same behavior. > > Debugging the code it seems that if the produced file is rather small, > the body after writing the file is converted into an InputStreamCache. > In these cases, the "pos" attribute of the InputStream is equal to the > "count" value, and any conversion to string leads to an empty string. > This seems logical. Still debugging, if I reset "pos" to "mark" (0 in > our cases), the next string conversion is correct. > > Is this resetting expected to be done by the file producer after > writing the file ? > > When files are bigger, I can't identify the exact class of the body > that my debugger refuses to print (the display appears as a list of > blocks). In these cases, we have never had any string conversion > issue. > > Any idea of the cause of this behavior ? > > Thanks for your help. > > Regards.
