Menu
▾
▴
jboss-dev-forums
|
From: genman <nu...@jb...> - 2005-07-29 16:46:50
|
In terms of a priority for JBoss, probably it's not a general feature many people would use, but it makes MDBs more useful for processing requests where certain resources need to do the work for particular messages are slow or unavailable. Alternatively, an easier way to dynamically deploy MDBs (with selectors) would be nice to have. Then some sort of interceptor or whatever could deploy a new MDB instance/thread pool to do the work for a certain message. I guess if you could take a deployed "template" MDB and via JMX deploy a "clone" with a different selector that would work well enough. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887332#3887332 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887332 |
|
From: <ad...@jb...> - 2005-07-29 17:11:24
|
You can already attach multiple invoker proxy bindings to an MDB. e.g. you can get an MDB to listen to multple topic subscriptions (either from the same jms server or different ones) So I guess the solution would be to have a "template invoker proxy binding" and add management methods to the MDB Container that lets you add/remove invoker proxy bindings with specific overrides like your selector. Such a solution would also apply to JCA1.5 with the "activation config properties". Why don't you experiment? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887333#3887333 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887333 |
|
From: genman <do-...@jb...> - 2005-09-22 00:53:23
|
"ad...@jb..." wrote : | So I guess the solution would be to have a "template invoker proxy binding" | and add management methods to the MDB Container that lets you add/remove | invoker proxy bindings with specific overrides like your selector. | This feature surfaced again at my company. I guess I don't understand the call flow. Here's the existing stack trace, where would this go? | com.example.MDB.onMessage | sun.reflect.GeneratedMethodAccessor171.invoke | sun.reflect.DelegatingMethodAccessorImpl.invoke | java.lang.reflect.Method.invoke | org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke | org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke | org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke | org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext | org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions | org.jboss.ejb.plugins.TxInterceptorCMT.invoke | org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke | org.jboss.ejb.plugins.LogInterceptor.invoke | org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke | org.jboss.ejb.MessageDrivenContainer.internalInvoke | org.jboss.ejb.Container.invoke | org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke | org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage | org.jboss.jms.asf.StdServerSession.onMessage | Would the code go into the JMSContainerInvoker, or after? I'll poke around, I just wanted to know if you had some place in mind. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3896179#3896179 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3896179 |
|
From: genman <do-...@jb...> - 2005-09-22 02:08:21
|
Okay, I think I see how this can work. Here's the general call flow. org.jboss.ejb.MessageDrivenContainer.internalInvoke calls its first interceptor. The invocation would need to include the MDB container configuration. This must provide enough object references and general data so that a new MDB can be deployed from a template configuration. Things that might be included: DeploymentInfo, MBeanServer, BeanMetaData, ServiceControllerMBean, etc. A new interceptor checks that onMessage is being called, and the JMS Message is examined. For this message, a special header is checked. If the POOL_ID for the message is not set, then the request is forwarded to the MDB. If a POOL_ID is set and it doesn't exist, then a new MDB is created with a selector that matches the POOL_IDs. To me though, it feels like selectors are the wrong method though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3896188#3896188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3896188 |
|
From: <ad...@jb...> - 2005-09-28 19:46:33
|
No the MessageDrivenContainer knows nothing about how it is invoked or what it invokes. Go back and read what I said then ask for clarifications. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3897792#3897792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3897792 |
|
From: genman <do-...@jb...> - 2005-10-03 23:41:38
|
Okay, I think I understand a lot better now. There is an object bound to JNDI that creates the ServerSessionPool which itself is a factory that implements ServerSessionPoolFactory. It seems reasonable to just extend/replace org.jboss.jms.asf.StdServerSessionPool with a version that does as I want. To get a single thread pool, it would make sense, then, to replace StdServerSessionPoolFactory to have threads tied to a pool that this class manages or at least has a reference to. (Each StdServerSessionPool created would share a common thread pool.) I can probably create what I want with this approach, though it would be nice to also change the signature of ServerSessionPoolFactory.getServerSessionPool() to allow for a more generalized configuration parameter object to get passed in. It seems like JCA 1.5 uses a work management model, so perhaps I should just wait for JCA 1.5? http://www-128.ibm.com/developerworks/java/library/j-jca2/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3898828#3898828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3898828 |
|
From: <ad...@jb...> - 2005-10-03 23:54:04
|
"genman" wrote : | I can probably create what I want with this approach, though it would be nice to also change the signature of ServerSessionPoolFactory.getServerSessionPool() to allow for a more generalized configuration parameter object to get passed in. | Agreed. anonymous wrote : | It seems like JCA 1.5 uses a work management model, so perhaps I should just wait for JCA 1.5? | | http://www-128.ibm.com/developerworks/java/library/j-jca2/ | You mean JBoss4? Or this: http://jira.jboss.com/jira/browse/JBAS-1434 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3898831#3898831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3898831 |
|
From: genman <do-...@jb...> - 2005-10-06 20:55:34
|
Hmm, I should have looked at the new JCA 1.5 adaptor, which is probably what I want to be working on, not the old JMS adaptor. It has more of what I want and more sane class interfaces. With values from activation options (JmsActivation), I can probably come up with some configuration keys that specify the appropriate behavior. The general is idea is that src/main/org/jboss/resource/adapter/jms/inflow/JmsServerSession.java onMessage(Message) would include some sort of "plug in" (like the DLQHandler) for generating new session pools with selectors based on the contents of the message. I don't yet know what it'll look like. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3899725#3899725 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3899725 |
|
From: <ad...@jb...> - 2005-10-06 21:12:32
|
"would include some sort of "plug in" (like the DLQHandler) for generating new session pools with selectors based on the contents of the message. I don't yet know what it'll look like." Yes, I'm hoping the inflow adapter will have a lot more pluggable components the JMSContainerInvoker is pretty rigid in terms of changing implementation/policy. :-( The current inflow rar still uses ConnectionConsumer/ServerSessionPool but I would prefer it to use JMS vendor specific plugins that will be capable of a lot more optimizations and behaviours/features (including workarounds for known "broken" vendors who only provide full behaviour through vendor specific api). If I only had time to work on it... :-) I believe Tim Fox is going to work on some of this for the new JBoss Messaging? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3899729#3899729 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3899729 |
|
From: genman <do-...@jb...> - 2005-10-07 20:06:14
|
"ad...@jb..." wrote :
| Yes, I'm hoping the inflow adapter will have a lot more pluggable components
| the JMSContainerInvoker is pretty rigid in terms of changing implementation/policy. :-(
|
This is going away, at least for the default configuration for 4.0? I'd rather not have to try to deal with the JMSContainerInvoker
"ad...@jb..." wrote :
| The current inflow rar still uses ConnectionConsumer/ServerSessionPool
| but I would prefer it to use JMS vendor specific plugins that will be capable of
| a lot more optimizations and behaviours/features (including workarounds for known
| "broken" vendors who only provide full behaviour through vendor specific api).
|
| If I only had time to work on it... :-)
| I believe Tim Fox is going to work on some of this for the new JBoss Messaging?
I thought JBoss Messaging was working on just the JMS implementation, not the EJB container and JCA 1.5 adaptor. And if I work on anything it'd be for the new .rar.
I was thinking that the org.jboss.resource.adapter.jms.inflow.DLQHandler had a fairly decent interface. Perhaps I would do the following:
| /**
| * An interface for inflow message Handling.
| */
| public interface InflowHandler
| {
|
| /**
| * Set up the handler.
| * @throws Exception for any setup failure
| */
| void setup(JmsActivation activation) throws Exception;
|
| /**
| * Tear down the handler.
| */
| void teardown();
|
| /**
| * Handles the message, return true if the message should not be further processed.
| */
| boolean handle(Message msg);
|
| /**
| * Notification that the message was delivered
| */
| void messageDelivered(Message msg);
|
| }
|
I would probably make DLQHandler a subclass of InflowHandler and change the signatures slightly. The activation parameters would include a list of classes. What do you think?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3899931#3899931
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3899931
|
|
From: <ad...@jb...> - 2005-10-07 20:18:17
|
We are trying to unify the "interceptor"s on the aop model. In future this will include the rar implementations, e.g. applying interceptors to the DataSource or inflow. I've already started a prototype here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70511 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3899935#3899935 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3899935 |
|
From: <ad...@jb...> - 2005-10-07 21:23:02
|
"ad...@jb..." wrote : We are trying to unify the "interceptor"s on the aop model. | This does not mean that until we get there, the old models cannot duplicate the behaviour. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3899952#3899952 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3899952 |
|
From: genman <do-...@jb...> - 2005-10-08 00:03:10
|
"ad...@jb..." wrote : "ad...@jb..." wrote : We are trying to unify the "interceptor"s on the aop model. | | | | This does not mean that until we get there, the old models cannot duplicate the | behaviour. Until the Aspect/POJOize JCA arrives, would the interceptor interface I suggested be appropriate? Is JCA 1.5 for MDBs going to be a 4.0 feature? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3899974#3899974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3899974 |
|
From: <ad...@jb...> - 2005-10-08 20:22:59
|
"genman" wrote : | Until the Aspect/POJOize JCA arrives, would the interceptor interface I suggested be appropriate? Is JCA 1.5 for MDBs going to be a 4.0 feature? I would assume it is NOT, even though the jury is still out. So yes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3900054#3900054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3900054 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X