Hi
Do you create a new client per every request ?
What might be happening is that in this case, when you have the
providers registered on the bus, every time a client is created it gets
a new ClientProviderFactory which in turn will mark on the current bus
that the bus providers have already been registered, using a factory
hash code - I think this may be the cause of the problem.
For now consider avoiding registering the providers on the bus - do it
on the client only. If the same bus (with the providers) is shared
between the clients and the server then create a client specific bus.
I'll reopen the issue next week
Cheers, Sergey
On 15/06/16 15:25, [email protected] wrote:
Thanks Alexey.
While waiting for answers to my earlier questions from the masters, I am
thinking of adopting a CXF interceptor (as a work around) to nullify the
contextCache reference, hoping that these unwanted map entries gets GCed
more frequently.
Your quick help is appreciated.
Regards,
Ranadeep.
On Jun 15, 2016 3:09 AM, "Alexey Markevich [via CXF]" <
[email protected]> wrote:
https://issues.apache.org/jira/browse/CXF-6823
On Tue, 14 Jun 2016 20:38:27 +0300, [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5769525&i=0>
<[hidden email] <http:///user/SendEmail.jtp?type=node&node=5769525&i=1>>
wrote:
*CXF Component/s:* Bus, JAX-RS
*Affects Version/s:* 3.1.0, 3.1.6
*Environment:* Redhat Enterprise Linux (Santiago), OpenJDK 7, Tomcat 7
We have an application with REST client components for making calls to
Backend web services. During our routine performance test, JProfiler
tool
shows lots of Bus property entries (with keys named
"bus.providers.set.")
populated while creating instances of ClientProviderFactory.
*public final class ClientProviderFactory extends ProviderFactory {
public static ClientProviderFactory createInstance(Bus bus) {
...
factory.setBusProviders();
...
}*
These Bus property entries seem to stay in heap for the whole duration
of
the 6 hour run. In fact, around 100,000 entries occupying 13 MB of heap.
In
short, GC doesn't seem to happening frequently enough to keep the heap
usage
within limits.
Is this some sort of a bug or, lack of necessary configuration in CXF to
optimize the creation/cleanup of these objects?
--
View this message in context:
http://cxf.547215.n5.nabble.com/Unwanted-bunch-of-Bus-Provider-objects-in-HashMap-occupying-large-volumes-of-heap-memory-tp5769515.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Regards, Alexey.
------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://cxf.547215.n5.nabble.com/Unwanted-bunch-of-Bus-Provider-objects-in-HashMap-occupying-large-volumes-of-heap-memory-tp5769515p5769525.html
To unsubscribe from Unwanted bunch of Bus Provider objects in HashMap
occupying large volumes of heap memory, click here
<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5769515&code=cmFuYWRlZXAuc2hhcm1hQGdtYWlsLmNvbXw1NzY5NTE1fC0xOTAyNzcwMDYz>
.
NAML
<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context:
http://cxf.547215.n5.nabble.com/Unwanted-bunch-of-Bus-Provider-objects-in-HashMap-occupying-large-volumes-of-heap-memory-tp5769515p5769533.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
