[
https://issues.apache.org/jira/browse/CAMEL-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244114#comment-13244114
]
Frank Kootte commented on CAMEL-3776:
-------------------------------------
Our code predominantly ( actually only ) uses the FallbackTypeConverter ( which
I originally patched ). Applying a patch with the same semantics as the patch
you applied to the FallbackTypeConverter would solve the issue for all ways to
apply JAXB conversions. A ThreadLocal instance containing a per Thread
Unmarshaller would be the cheapest solution ( in this case I am comparing it to
pooling ) I figure - it would however retain the memory until ( if! ) the
spawned Threads would be removed from the application server ThreadPool
releasing their resources and making them available for GC - which would be
more controllable given the Pool usage. What is your vision upon the subject
exactly ? Perhaps - while we are at it - we should also look into removing the
duplication we see in that region and have a single solution for both callsites.
> Add pooling support for JAXB data format
> ----------------------------------------
>
> Key: CAMEL-3776
> URL: https://issues.apache.org/jira/browse/CAMEL-3776
> Project: Camel
> Issue Type: New Feature
> Components: camel-jaxb
> Reporter: Claus Ibsen
> Fix For: 3.0.0
>
> Attachments: jaxb-pool.patch
>
>
> We should use the ServicePool in camel-core to pool JAXB / marshaller /
> unmarshaller.
> Of course ppl should be able to customize pool settings and if to be used.
> Also mind that for type converters with JAXB you do not configure a JAXB data
> format. And thus we should
> still be able to configure and use pooling, so the type converter can be more
> efficient.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
