Umsetzungsmöglichkeit Stapelverarbeitung

Hallo,

schon klar, aber ich schrieb deshalb ja auch extra:
asynchron darauf zu reagieren.
Empfangen werden die AEs synchron aber von da aus kann man trotzdem eine asynchrone Verarbeitung starten (entweder über Quartz, CommonJ oder doch was eigenes über einen ExecutionService).

Gruß Tom
 
Hallo ihr zwei,

danke für die rege Beteiligung an dem Thema :D
Da ich mich noch nicht lange mit JEE und allem was daran hängt beschäftige, muss ich mich wohl zunächst noch mit den ganzen Begriffen die hier gefallen sind auseinandersetzen.
Leider habe ich im Moment nicht die Zeit mich in Spring einzulesen und alles bisher für das Projekt erarbeitete darin umzusetzen. Später werde ich sicherlich darauf zurückkommen da es ja anscheinend Argumente gibt, die dafür sprechen.


Was ich bisjetzt erfahren habe, ist wohl eine Lösung mit JMS in Zusammenhang mit meiner Umgebung die Eleganteste und werde versuchen ein paar Beispiele zu finden die mir den Vorgang verdeutlichen.

Vielen Dank nochmal und Daumen hoch

Andreas
 
Hi, wollte kurz mitteilen wie ich die Sache nun in meiner Umgebung(JBoss AS und Seam-gen 2.0.CR1) gelöst bekommen habe.

Queue deklarieren:
XML:
<?xml version="1.0" encoding="UTF-8"?>
<server>
  <mbean code="org.jboss.mq.server.jmx.Queue" 
       name="jboss.mq.destination:service=Queue,name=OatsMessageQueue"> 
    <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
    <attribute name="JNDIName">queue/OatsMessageQueue</attribute>
  </mbean>
</server>

speichern in myapp-service.xml (myapp kann auch anders lauten) unter dem resources Ordner im Projekt und in build.xml hinzufügen.

build.xml
XML:
<target name="jar" depends="compile,copyclasses" 
                        description="Build the distribution .jar file">
                <copy todir="${jar.dir}">
                        <fileset dir="${basedir}/resources">
                        	<include name="oats-service.xml"/>
                        </fileset>
                </copy>
        </target>

Oder von Hand eintragen <server>:8080/jmx-console -> Service "jboss.mq" -> DestinationManager -> createQueue. (1. <Queue-Name> 2. queue/<Queue-Name>). Sollte danach untere: Service "jboss.mq.destination" gelistet sein.

Sender wie hier beschrieben: http://docs.jboss.com/seam/2.0.0.CR1/reference/en/html/jms.html#d0e11514

Empfänger(MDB):
Java:
@MessageDriven(name="TestMessageBean", activationConfig = {
    @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
    @ActivationConfigProperty(propertyName="destination", propertyValue="queue/TestMessageQueue")

})
@PoolClass(value=org.jboss.ejb3.StrictMaxPool.class, maxSize=1)
public class TestMessageBean implements MessageListener {

    @Resource
    private MessageDrivenContext context;

    public void onMessage(Message message) {
    	UserQuery name = null;
        try {
            if (message instanceof ObjectMessage) {
                ObjectMessage objMessage = (ObjectMessage) message;
                Object obj = objMessage.getObject();
                if (obj instanceof UserQuery) {
                    name = (UserQuery) obj;
                    name.query();
                    System.out.println("****************************************************");
                    System.out.println("LongProcessMessageBean.onMessage(): Received message. NAME: "+name.time());
                    
                 } else {
                    System.err.println("Expecting ProcessDTO in Message");
                }
            } else {
                System.err.println("Expecting Object Message");
            }
        } catch (Throwable t) {
            t.printStackTrace();
            context.setRollbackOnly();
        }
    }     
}

@PoolClass ist nicht unbedingt notwendig. Durch den Parameter maxSize=1 wird die MDB quasi als Singleton deklariert damit in meinem Fall auch wirklich eine nach der anderen Message verarbeitet wird.

Hoffe es ist einigermaßen verständlich.

Kritik und Anregungen nehme ich gerne entgegen.
 
Zuletzt bearbeitet von einem Moderator:
Hm, sieht ja doch recht übersichtlich aus. Auch wenn sich mir bei diesem Annotationswahnsinn die Fußnägel hochrollen. (Thema Vermischung von Code und Konfiguration).

Die System.out.println bzw. das ExceptionHandlingAntipattern ist wahrscheinlich dem Democharakter geschuldet, oder? ;)

Ansonsten, cool, dass es so tut... Ich such vielleicht nochmal den Code von nem Springprojekt raus, was ich vor einer Weile laufen hatte, da blieben die Klassen völlig frei vom Wissen um die Asynchronität. Das war IMHO noch ein Stück eleganter...

REINHAUN!
 
Zurück