[JBoss Messaging Users] - Queue-like/Persistent Topics
by driveraf
Hello everyone, this is my first post.
I have a question/problem for which I think I have an answer/solution. What I need is sort of a hybrid between a queue and a topic (unless there's a topic configuration that already does what I want).
I *already* have a service that every once in a while (say 10 msg/min) publishes messages to a Topic. I can then have multiple clients connect to this topic, subscribe and receive messages *as they are published*.
But I need the option to retrieve those messages that have already been published before subscribing, like a JMS Queue, which stores messages waiting to be consumed.
A more concrete example of what I *NEED*:
1. Service (i.e. the Message Publisher) starts up.
2. Publisher sends 10 messages.
3. Client 1 connects, subscribes and receives those ten messages, along with any new messages
4. Publisher sends 10 more messages; Client 1 receives them
5. Client 2 connects, subscribes and receives 20 messages, then any new messages
6. Publisher keeps sending messages and Clients 1 & 2 receive them.
Now, all I have been able to do is receive messages after subscribing. All messages published before subscribing are lost. I've searched high and low and have found no standard (i.e. configurable) way to do what I want.
I do have a work-around, but I am not too sure that it is the best way to go (the best way might be some configuration I've overlooked). I can have the publishing service create a certain amount of persistent subscriptions at start-up (i.e. create 30 subscribers named 'Subscriber-n", where n goes from 1 to 30), disconnect each of these 30 subscribers immediately, and then have the clients connect using one of these pre-created subscriptions. Since the subscriptions are persistent, they will receive every message since start-up.
I know a database should work as well, but I need to use JMS.
Any suggestions or comments?
Thanx,
Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252505#4252505
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252505
13 years, 6 months
[EJB 3.0 Users] - PortableRemoteObject.narrow() still needed in EJB3 / Jboss A
by henk53
Hi,
In a lot of EJB3 example code I often encounter the use of PortableRemoteObject.narrow() to do a sort of double casting from the Object obtained from JNDI to the target EJB (remote) interface.
However, I found that at least in Jboss AS 5 I never seem to need to do this 'double casting'. Both local references and more importantly remote references, even when truly obtained in a remote JVM, can be directly cast to the required interface.
I found this old blog posting: http://www.bright-green.com/blog/2003_04_03/portableremoteobjectnarrow_mu... it tries to explain why PortableRemoteObject.narrow() was needed in the first place, but I just don't see the logic. The rationale seems to be that some obscure other languages might not have casting and thus need such a method. Java however does have native casting, but somehow still needs or needed this method.
I found another explanation in Mastering EJB 4th Edition:
anonymous wrote :
| After looking up the remote object, we perform the operation javax.rmi.PortableRemoteObject.narrow(). This is a static method on an RMI-IIOP class called PortableRemoteObject. This method casts the generic object that we looked up via JNDI to our RMI-IIOPinterface type. This narrow() operation is required whenever you look up an RMI-IIOP object via JNDI. Why do we need it, and why don't we just cast it using a regular Java cast? The short answer is that the networking layer needs a chance to sneak in and create the necessary stub objects. Obviously, the code for these stubs must be available at this time. In most cases, that requires that the rmiccommand has been run previously to generate them.
|
That too doesn't sound very logical, since JNDI is an interface anyway and the SPI implementation can always return that stub too of course if PortableRemoteObject.narrow() is able to do it.
My question now is, is PortableRemoteObject.narrow() completely deprecated or is it still needed for some specific use cases?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252499#4252499
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252499
13 years, 6 months
[jBPM Users] - Error from Fork element with transitions to FreeMarker forms
by pektop
Hello,
The problem is that I need to fork workflow, and got his error in jBPM console:
| root cause
| java.lang.NullPointerException
| org.jbpm.integration.console.forms.TaskFormDispatcher.provideForm(TaskFormDispatcher.java:149)
| org.jbpm.integration.console.forms.FormDispatcherComposite.provideForm(FormDispatcherComposite.java:65)
| sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| java.lang.reflect.Method.invoke(Method.java:597)
| org.jboss.bpm.console.server.util.InvocationProxy.invoke(InvocationProxy.java:64)
| $Proxy143.provideForm(Unknown Source)
| org.jboss.bpm.console.server.FormProcessingFacade.provideForm(FormProcessingFacade.java:181)
| . . . . .
|
Here is the fork element from the jpdl file:
| <fork name="fork1" g="176,568,48,48">
| <transition to="Pay manufacturer's bill"/>
| <transition to="Make installations"/>
| </fork>
|
"Pay manufacturer's bill" and "Make installations" are transitions to .ftl forms. If I remove fork element and transition from previous element goes directly to these task elements then everything woks fine. But I need to split the workflow, and fork element is the only way how to do it.
- What I need to do for get fork working?
BR
Oleg Ladizhensky
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252497#4252497
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252497
13 years, 6 months