I am facing a strange situation while using HornetQ.
My application architecture -
JMS provider : HornetQ (Standalone server, not used for anything else. I've created 2 queues on this server, say Q1 and Q2).
Producer : A web application deployed on a separate machine. This application creates instances of "ObjectMessage", passing a "Job" class instance as argument to the "ObjectMessage.setObject()" method and adds the message to Q1. Uses Spring JMS.
I also set a string property named "AGENT" in the message before adding it to the queue.
What's peculiar is that if I call ObjectMessage.setStringProperty("AGENT", null) or if I do not add the property to the message itself, the message does not get added to Q1. However, this does not happen on Q2, and I'm able to see the message in HornetQ's JMX console.
Is there some queue specific configuration that I should be looking out for?
Apologies for the loose wording - My team and I have been facing a tough time trying to fix this issue.
Thanks.
How are you creating the Producer? and How are you sending it?
It seems you're not committing on a transactional session?
I'm assuming you are using JMS, but I would need to see some code to help you in a better fashion. Usually the JBoss Forum is a better suitable place for discussions like this, since the SOF is not really a discussion forum.
I think the best would be you open a forum on JBoss (since it will be followed by a discussion) and provide the link here.
Related
We have a spring boot application that is growing in complexity because of integration needs - like send an email after you do this, or broadcast a jms message after you that etc. In looking for some higher level abstractions, I came across apache camel (haven't used camel ever before). The question that I have is what do I do with the spring boot application? The application has the standard spring controllers, services and uses spring-data for connecting to databases. I didn't find much help online on how to merge camel into a spring-boot restful application. Is that even something that is doable or is camel a completely different beast that the spring boot won't fit?
I did read that Camel tightly integrates with Spring, but still I didn't know if 1) Spring Controllers are still something that can be used along with Camel 2) If I can call the other spring beans from camel routes and whether I can call invoke a camel route from a spring bean (sorry if these sound like camel newbie questions to the experts)
As an example of what we have to do:
After finishing writing anything to the database about an order, we have to send an email out to the order processing department
If someone deletes a particular user address, we have to send to a jms topic so other applications can take action.
Every http request is coming in through the Spring MVC stack today.
Is there a way to "hand-off" the processing to camel after a particular task is complete? (like writing the order to the database successfully via the Spring MVC stack and hand off to camel to send a jms message and do other things)? Or should we completely replace Spring with Camel?
Not sure what the right path is. Can someone please guide us?
This question is slightly old, but though it was worth mentioning here that Apache Camel now includes a Spring Boot component.
Details can be found here
http://camel.apache.org/spring-boot.html
and they document an example here
http://camel.apache.org/spring-boot-example.html
Follow this for the current best practice in camelising a spring boot application!
One option is to
1> define camel routes either in Spring DSL or Java DSL or other means and define it in Spring Application context.
2> And have a class that implements ApplicationContextAware and cache the Spring ApplicationContext in a Static Variable.
3> For #Controller we can get this static variable and get hold of ApplicationContext .
4> With the camel context ID we can do a getBean from ApplicationContext.
5> This is the instance of DefaultCamelContext,with this we can do a createProducer and call camel routes from #Controller.
Like some others mentioned, spring-boot-camel (but use spring-boot-camel-starter as your dependency) works very well and it is really easy to set up. When you annotate your RouteBuilder extensions and your Processor implementations with #Component, they wire up directly into the context and you are good to go. Then, you can #Autowire a CamelContext or a ProducerTemplate into your classes and use them as necessary.
You asked about how Controllers can work with Camel, and if you #Autowire any of the things you need (probably a context or a producer template), then the answer is a definite "yes" that you can use them together quite easily. And when you use spring-web, your context will start and remain running without any additional configuration, etc.
Like Matthew Wells suggested, the links will get you pointed in the right direction. If you, or others on your team, are at all familiar with Camel, then it will be very easy for you to do what you need to do. But, ah, I notice that this question is from 2014, and you're probably well past the point of your question. At least if anyone else stops by this thread, they will have plenty of information to get going. If you come by and re-visit your question, please let us know how it went for you, and what you ended up doing. Cheers!
the glassfish application server provides a nice monitoring REST interface.
To use it u can enable several monitorable items in the admin console, for example the EJB container. The documentation says, you can retreive EJB-statistics for every deployed application.
If you request a URL like localhost:4848/monitoring/domain1/server/applications/APPNAME/EJBNAME you will get statistics for a given EJB of the application.
Further, there is a possibility to look more deeply into each bean-method of the ejb, for example the executiontime, about which the documentation says:
"Time, in milliseconds, spent executing the method for the last successful/unsuccessful attempt to run the operation. This is collected for stateless and stateful session beans and entity beans if monitoring is enabled on the EJB container."
The problem now is, monitoring is enabled on the EJB-container (Level set to HIGH), but nothing is sampled in any bean-method in any EJB in any deployed application.
Is there something special to do in the bean and/or the glassfish ?
Thanks in advance for help,
Chris
EDIT:
Ok, I noticed something more about that behaviour:
In the server log you get a log message for each deployed EJB like that:
INFO: EJB5181:Portable JNDI names for EJB DataFetcher // ...
If I set the ejb-container monitoring level to HIGH (which is what I want to do), I get the following warning for each deployed EJB, regardless which app I deploy:
WARNING: MNTG0201:Flashlight listener registration failed for listener class : com.sun.ejb.monitoring.stats.StatelessSessionBeanStatsProvider , will retry later
I googled the warning but none of the resulst really help me enabling EJB monitoring...
This seems to be a Bug in Glassfish.
EJB Monitoring is currently not working in 3.1.2.
JIRA issue is already raised: http://java.net/jira/browse/GLASSFISH-19677
There is nothing "special" to do.
http://docs.oracle.com/cd/E18930_01/html/821-2431/abeea.html
For me it seems as if you probably enabled the monitoring option on the wrong configuration. Please double check.
To get rid of this message you can disable the monitoring on ejb container option below in the image
From Monitor Data--->Configure monitoring--->make ejb container log off
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.
Search did not give me a hint, how can i behave with the following situation:
I'd love to have 2 OSGI implementations of the same interface: one is regular, the other should work (be active/present/whatever) on the given time period (f.e for Christmas weeks :))
The main goal is to call the same interface without specifying any flags/properties/without manual switching of ranking. Application should somehow switch implementation for this special period, doing another/regular job before and after :)
I'm a newbie, maybe i do not completely understand OSGI concept somewhere, sorry for that of give me a hint or link, sorry for my English.
Using Felix/Equinox with Apache Aries.
The publisher of a service can register and unregister that service whenever it likes using the normal API. If it chooses then it can do so according to some regular schedule.
If there is another service instance that is available continuously, then the consumer of the service will sometimes see two instances of the service and sometimes see one. When there is only one instance available then it is trivial to get only that instance. When there are two instances then you need a way to ensure you get your "preferred" instance. The SERVICE_RANKING property is a way to do this. The getService method of a normal ServiceTracker will always return the higher ranked service, so this would appear to satisfy your requirement.
I have yet to see an OSGI container that at a framework level supports date/time based availability of services.
If I were you I would simply drop a proxy service in front of the two interface implementations and put the service invocation based on date logic in there.
I don't believe there is any framework support for what you are asking for.
If you are intent on avoiding service filters, you might try this.
Implement a PolicyService. This service is in charge of deciding which instance of your service should be registered at a given point in time. When its time for the policy service to switch implementations, it just uses the register/unregister apis as usual. You policy service implementation can read in a config file that specifies the date range to service implementation mapping. This will allow you to add new behavior by modifying your config file and installing a new bundle with the new service.
I agree with Neil that a service should only publish itself if it can actually be invoked. My solution to this problem would be to have all service producers be dependent on a "time constraint dependency". Whilst such a dependency is not available in the standard dependency frameworks (like Declarative Services, Blueprint, iPOJO) it is easily implemented with the Apache Felix Dependency Manager, which allows you to create your own types of dependencies. Note that writing such a new dependency once is some work, but if this is a core piece of your application I think it's worth it. Service consumers would not require any special logic, they would simply invoke the service that was there.
Ok, what i have finally done...
Implemented a common dispatcher bundle - and call any of services only thru it (therefore cron is not needed, when call is on-demand)
When dispatcher obtains request - it searches for interface in its own cache and -
When there are >1 service with the same ranking and both are equal (registered) - then
Dispatcher resolves needed service via own written #TimigPolicy annotation with "from" and "to" fields
For the given server new datetime() - dispatcher returns proper service instance
Much work, i should say :) But works nearly perfect :)
Thanks everybody for giving me hints, it was really helpful!!!
Does anybody has an experience with Spring Integration project as embedded ESB?
I'm highly interesting in such use cases as:
Reading files from directory on schedule basis
Getting data from JDBC data source
Modularity and possibility to start/stop/redeploy module on the fly (e.g. one module can scan directory on schedule basis, another call query from jdbc data source etc.)
repeat/retry policy
UPDATE:
I found answers on all my questions except "Getting data from JDBC data source". Is it technically possible?
Remember, "ESB" is just a marketing term designed to sell more expensive software, it's not a magic bullet. You need to consider the specific jobs you need your software to do, and pick accordingly. If Spring Integration seems to fit the bill, I wouldn't be too concerned if it doesn't look much like an uber-expensive server installation.
The Spring Integration JDBC adapters are available in 2.0, and we just released GA last week. Here's the relevant section from the reference manual: http://static.springsource.org/spring-integration/docs/latest-ga/reference/htmlsingle/#jdbc
This link describes the FileSucker with Spring Integration. Read up on your Enterprise Integration patterns for more info I think.
I kinda think you need to do a bit more investigation your self, or do a couple of tries on some of your usecases. Then we can discuss whats good and bad
JDBC Adapters appear to be a work in progress.
Even if there is no specific adapter available, remember that Spring Integration is a thin wrapper around POJOs. You'll be able to access JDBC in any component e.g. your service activators.
See here for a solution based on a polling inbound channel adapter too.