Hi All-

I have a java ACI server that receives persisted messages from a Natural client on the mf. I am trying to run 2 treaded instances of my java server. One thread calls receive() and the second calls receiveOld(). When the second thread is started I get the 196/196 Broker error.

My questions:

Is there a way to get around this error?

Is anyone using a better design to process both new and old messages within the same server program?


Thanks in advance,
Chris Webber
State of Minnesota

a 196/196 indicates that a reconnection is taking place, which indicates that you are using the same userid/token pair on both threads. Try setting the token to something different (such as the thread number) and see if that helps.

You might also use RECEIVE,OPTION=ANY which will let the same thread see both new and old messages. CONV-STATUS indicates the type of conversation (new, old or none) when a message is received.

Douglas Kelly,
Principal Consultant
Software AG, Inc
Sacramento, California

Hi Chris,

as Douglas has already pointed out the following approach is probably the easy way to go: just use one thread with receiceAny(). You might add more threads (but all have to have different userid/token pairs) to support parallel processing.

Receive logic could look like this:

while (true) {
try {
msg = UnitofWork.receiveAny(server, "NO");
u = msg.getUnitofWork();
System.out.println("received: " + u.getUnitofWorkID());
}
catch (BrokerException e) {
if ((e.getErrorClass() == 3 && e.getErrorCode() == 3)
// no matching conversation found
|| (e.getErrorClass() == 74 && e.getErrorCode() == 74)
// Wait timeout occurred
|| (e.getErrorClass() == 74 && e.getErrorCode() == 300)) {
// Conversation found no units of work
System.out.println("No UnitofWork found");
break;
}
else if (e.getErrorClass() == 74 && e.getErrorCode() == 301)
// Conversation found end of unit of work
u.commit();
else {
System.out.println(e);
break;
}
}
}

Thanks Rolf and Douglas but I suppose I should explain a little more of my business need.

As I said, I receive a message from Natural. I then process the message in java which inclues parsing it and putting it in a SOAP envelope and sending it to a web service at an outside .NET agency. I get a resonse code from that agency. If the response is good, I committ the UOW. If not a good response code I need to back out the status of the uow to be resent to the agency later in the day. We used ACI to guarantee delivery via persistence.

If I used a receiveAny() I am guessing that this could cause looping of the same message if it is the result of a bad return code.

I also assume that with 2 threads and different tokens that I wouldn’t be able to access the backed out uow message for reprocessing.

Is ther a better way to do this?

If the PSTORE for UOW is on adabas, can I access that file via Natural and somehow initiate reprocessing from there?

Thanks,
Chris

There is no simple solution to achieve something I would call mark messages for later processing (if I understood correctly what you are trying to achieve). However I see two possibilities:

• Use a separate queue (service) for these messages. So when the web service returns an error send the message to the second queue and commit both the original and the newly created message. The “delayed” messages can then be retrieved at a later time (or even in parallel if this makes sense) by the same or by a different thread/user.
  
• The processing loop in the server reads only new messages via uow.receive(). In case the call to the web service fails don’t backout the uow but store it in a collection object (e.g. a Java Stack instance). Later in the day you can process the uows in the stack and backout them thus restarting their evaluation.
  

One more time and then we can put this to rest.

Is the ‘persistence’ considered achieved or satisfied when I successfully receive the message in my java server? In other words, am I using persistence differently than it is intended?

Also, what do other applications/shops do with the backed out message that gets put to pstore? Do they use another application to reprocess or do they just log it and not reprocess?

Finally, Thanks for all the help. You guys know your product very well.

Chris Webber

Not really sure if this answers your question: There is a chapter titled Using Persistence and Units of Work in the docu which describes some of the details of UOW processing. Check the diagram which shows the different state transitions for UOW status. The relative URL to the diagram is admin/persist/using.htm#Understanding_UOW_Status.

Kind regards,
Rolf