-
1. Re: multiple bean instances as services
kcbabo Mar 13, 2014 4:22 PM (in response to chz29)There is one instance of each bean implementation per application. Promoting a bean component multiple times will not result in multiple instances.
Based on the switchyard.xml snippet you provided, I assume that the processing logic is identical between instances and you just want to have localized state, right? If there's something in the messages that can be used to identify the source system, then you can use that in combination with a local map (keyed by instance id) in the implementation or use an external store like a database to hold the state. If the message doesn't provide that detail, you can use context details like the service name and/or binding name to differentiate between source systems.
Hope that helps. If I misunderstood your requirement, let me know.
-
2. Re: multiple bean instances as services
chz29 Mar 13, 2014 5:22 PM (in response to kcbabo)Thanks for the clarification. My final input rate of relatively small messages should be about 60-90/sec total from 18 custom camel endpoints, should I be concerned with performance and throw a route/seda queue combo in front?. Also, I see in BeanComponentActivator source that you are pulling just the local part off the QName for the ServiceProxyHandler. Any plans in future releases to pull the namespaceURI and allow multiple handlers/bean pools for non-CDI/local bean kind of instances?
-
3. Re: multiple bean instances as services
kcbabo Mar 24, 2014 7:45 PM (in response to chz29)1 of 1 people found this helpfulSorry for the late response. For some reason, I didn't get a forum notification for your response.
My final input rate of relatively small messages should be about 60-90/sec total from 18 custom camel endpoints, should I be concerned with performance and throw a route/seda queue combo in front?.
It really depends on the execution time of the bean method and the scope of the synchronization in your code. If you are only synchronizing a small part of the logic which updates the shared state, and that operation is quick, then there may be no need to have multiple instances. I would definitely test with the bean alone first and see what kind of performance you get. If you find that you can't get to the numbers you want, then adding a route with a seda endpoint to get asynchronous dispatch is worth looking at, although there are some trade-offs there (transaction scope being one).
Also, I see in BeanComponentActivator source that you are pulling just the local part off the QName for the ServiceProxyHandler. Any plans in future releases to pull the namespaceURI and allow multiple handlers/bean pools for non-CDI/local bean kind of instances?
Within the scope of an application, all services provided by CDI beans will have the same namespace. That's why we only use the local name. Bean pooling has been discussed as a possible enhancement in the past - if it's a feature you would like to see, please file an enhancement request with background on what you would like to see.
regards,
keith
-
4. Re: multiple bean instances as services
chz29 Mar 25, 2014 9:37 PM (in response to kcbabo)I'll give it a go on the single instance and crank up the volume. If it doesn't work out I'll file that enhancement request.Thanks, Keith!