I'm checking one project code; in spring.xml I see that 'amq:broker' is configured for input and output. Along with this configuration, ActiveMQConnectionFactory>PooledConnectionFactory>JmsConfiguration>ActiveMQComponent are also configured.
I need to know what is 'broker' element and why it is required and how it is different from 'brokerURL' of ActiveMQConnectionFactory.
'Broker' section of http://activemq.apache.org/ is little confusing :)
The broker declaration is needed if you want to run ActiveMQ embedded in your VM. You can use the connection factory as well to set up an embedded broker if you use the vm-transport, albeit this offers limited configuration options for the broker.
The connection factory you need to, well, create new connections to a broker. Independent of whether it is embedded or runs externally. For that the factory needs to know where to connect to and what transport to use.
Related
I want to run few tasks asynchronously in a web application. My question is which Spring implementation of task executors i should use in a Container managed environment.
I refereed to this chapter in Spring documentation and found few options.
One option I considered is WorkManagerTaskExecutor. This is very simple and works seamlessly with the IBM Websepher server which I'm currently using but this is very specific to IBM Websphere and Oracle Weblogic servers. I don't want to tie my code specifically to one particular implementation as in some test and local regions we are using Jetty container & this implementation creates problems to run the code in Jetty.
Other options like SimpleThreadPoolTaskExecutor does not seem to be best fit to leverage thread pooling in container managed environment and I don't want to create new thread myself.
Could you pleas suggest how do I go about this. Any pointers to a sample implementation will be great help.
As usual, it depends. If you rely on the container's thread management and want to be able to set thread pools on its admin interface or if you're application is not the only app inside the container or you use specific features like setting thread pool priorities for EJB or JMS you should add support for the WorkManagerTaskExecutor and make it configurable. If not, you can use whatever you want cause in the end threads are just threads. Since Spring is an IOC container you can do it. To use the same app everywhere I wouldn't suggest to change the XML config per app version. Rather
use profiles with configuration to set the executor type and inside your java config return the proper bean type. If you use Jetty you should have a configuration for the thread pool sizes to to be able to tune it.
use spring boot like auto configuration which usually rely on available classes on classpath (#ConditionalOnClass). If your weblogic or websphere specific classes are available or any other container specific thing like env variables you can create the WorkManagerTaskExecutor
With both of these you can deploy the same war everywhere.
WSO2 Identity Server 5.0.0 (and some patches ;))
It does not appear that custom JDBC user store managers (child of JDBCUserStoreManager) use a JDBC pool. I'm noticing that I can end up session closed errors and sql exceptions whereas the Identity Server itself is still operating OK with its separate database connection (a configured pool).
So I guess I have two questions about this:
Somewhere up the chain, is there a JDBC pool for the JDBCUserStoreManager? If so, are there means to configure that guy more robustly?
Can I create another JDBC datasource in master-datasources.xml which my custom JDBC user store manage could reference?
Instead of using your own datasources/connections, you can import Carbon Datasources and use those (they come with inbuilt pooling and no need to worry about any configurations etc). You can either access these programmatically by directly calling ndatasource component or access them via JNDI.
To access them directly from ndatasource component:
The dependency:
<dependency>
<groupId>org.wso2.carbon</groupId>
<artifactId>org.wso2.carbon.ndatasource.core</artifactId>
<version>add_correct_version_here</version>
</dependency>
(You can check repository/components/plugins to find out the correct version for above dependency)
You can inject DataSourceService as in this code (the #scr.reference tag refers to the service you need to inject, this uses maven scr plugin to parse these dependencies when building the bundle).
Note that when you follow this approach you'll have to build the jar as an OSGi bundle as it uses declarative services (and have to place it in repository/components/dropins). Otherwise the dependencies won't be injected at runtime.
Next, you can access all the data sources as:
List<CarbonDataSource> dataSources = dataSourceService.getAllDataSources();
Rajeev's answer was really insightful and helped with investigating and evaluating what I should do. But, I didn't end up using that route. :)
I ended up looking through the Identity Server and Carbon source code and found out that the JDBCUserStoreManager does end up creating a JDBC pool configured by the properties you set for that manager. I had a class called CustomUserStoreConstants for my custom user store manager which had setMandatoryProperty called by default to set:
JDBCRealmConstants.DRIVER_NAME
JDBCRealmConstants.URL
JDBCRealmConstants.USER_NAME
JDBCRealmConstants.PASSWORD
So the pool was configured with these values, BUT that was it...nothing else. So no wonder it wasn't surviving the night!
It turned out that the code setting this up, if it found a value for the JDBCRealmConstants.DATASOURCE in the config params, it would just load up that datasource and ignore any other params set. Seeing that, I got rid of those 4 params listed above and forced my custom user store to only allow having a DATASOURCE and I set it in code with the default JNDI name that I would name that datasource always. With that, I was able to configure my JDBC pool for this datasource with all params such as testOnBorrow, validationQuery, validationInterval, etc in master-datasources.xml. Now the only thing that would ever need to change is the datasource's configuration in that file.
The other reason I went with the datasource in the master-datasources.xml is that I didn't have to decided in my custom user store's code which parameters I would want to have or not have and just manage it all in the xml file easily. This really has advantages with portability of configs and IT involvement for deployments and debugging. I already have other datasources in this file for the IS deployment.
All said, my user store is now living through the night and weekends. :)
I have a spring based web-application that needs to get data from ActiveMQ via a JMX connection.
I am using MBeanServerConnectionFactoryBean (in Spring) to get various MBean attributes from ActiveMQ.
I have only one MBeanServerConnectionFactoryBean as a member variable, which is used to get the data. If multiple requests/threads come concurrently will there be any issues? Will there be any race conditions?
Please suggest the best way to keep the code thread-safe.
Spring FactoryBean objects are not intended to be used directly from your code, they're supposed to be used in your Spring config. As such, they are designed to be executed once and once only.
If you want to use them, including MBeanServerConnectionFactoryBean, then you need to create them, configure them, use them and discard them each and every time you want to get the object they create. They are most definitely not thread-safe.
Better yet, do it as the design intended and use them in your Spring config.
I'm currently developing a small EJB 3 application for WebSphere AS 7 with WebSphere-MQSeries. It's a very simple app that mainly consists of one MDB listening on a queue, convert the incoming messages and write the extracted data into a db. I've finally got up it and running, but I'm a bit confused regarding ActivationConfig annotations in the code, the ibm-ejb-jar-bnd.xml and the activation spec in WAS itself. My main question is, why do I need ALL of them? Why should/could I specify things like the queue name or destinaton type via annotation (#ActivationConfigProperty) when I still need a activation spec in WAS where I also specify the destination e.g. Queue-Name? I addition I also need a binding via an xml file? Is that right? Is it also possible to specify the activationspec-name via annotation and thus get rid of the xml binding file? Can I avoid creating the activation spec in WAS?
Hope someone can clarify things, thanks.
You cannot avoid the Activation Spec entity because it is responsible to open connection to your JMS provider, query messages according to various options like the message selector filter.
According to WebSphere 7 InfoCenter EJB-3 annotations can replace activation specification properties from binding file but the properties required by WebSphere are not standard.
So as far as I know, you have to provide:
either the binding file, written manually or edited with the deployer tool
either at deployment setting properties in the administrative console or in automated jython/wsadmin script
Be aware that the Activation Spec is a runtime component that can be stopped, typically after some rollbacks on messages. In that case, it no longer consumes message and your MDB has nothing to process until you re-activate it from the WebSphere console.
In WebSphere, if you code opens two concurrent database connections, you get an error of the form:
J2CA0086W: Shareable connection MCWrapper id 556e556e Managed connection WSRdbManagedConnectionImpl#52365236 State:STATE_TRAN_WRAPPER_INUSE
from resource jdbc/abc was used within a local transaction containment boundary.
Our framework allows us to do so (nested transactions which can be on a separate connection or multiple named transactions). I've seen lots of references to turning off some switch in WebSphere to turn on connection sharing but no details on how to set this flag. Can someone point me to the steps to achieve this?
Specifically, if you see this article: http://www-01.ibm.com/support/docview.wss?rs=180&context=SSEQTP&dc=DB520&dc=D600&dc=DB530&dc=D700&dc=DB500&dc=DB540&dc=DB510&dc=DB550&q1=j2ca0086w&uid=swg21121449&loc=en_US&cs=utf-8&lang=en
under "Resolving the problem" I want to know how to set the connection pool to be unshareable (assuming that indeed solves the problem).
What version of IBM WAS are you using? If you have WAS 8, go to
Resources-> JDC-> Datasources-> your datasources -> WebSphere Application Server properties -> Datasources no transactional.
Sorry for my english.
The message happens when dataSource.getConnection() is called twice in
a servlet. The datasource jdbc/oracle is lookup from local reference.
Call it once and reuse the connection or call con.close() before doing the 2nd getConnection()