Kenneth,
We have forced an exception in the onMessage() method, by declaring an
int x=1/0; It throws an arithmetical exception. Our configurations are
default, in this case it should be trying to do it for 6 times, but
after one failure, it doesnot rollback, due to the settings. Is there
any method, we need to call to have it rollback.
Kiran
public void onMessage(Message message) {
ObjectMessage msg = null;
File workingInputFile = null;
TranscodeRequest transcodeRequest = null;
TranscodeResponse videoTranscodeResponse = new
TranscodeResponse("Transcode complete");
try {
if (message instanceof ObjectMessage) {
msg = (ObjectMessage) message;
if (msg.getObject() instanceof TranscodeRequest) {
transcodeRequest = (TranscodeRequest) msg.getObject();
transcodeRequestID = transcodeRequest.getId();
videoTranscodeResponse.setTranscodeRequestID(transcodeRequestID);
videoTranscodeResponse.setTags(transcodeRequest.getTags());
try {
workingInputFile =
WorkingFile.getWorkingFile(transcodeRequest.getInputURL());
} catch (FileNotFoundException fileNotFoundException) {
TranscodeLogger.log(
videoTranscodeResponse.getTranscodeRequestID(),
Level.WARNING, fileNotFoundException.toString());
sendFailedTranscodeResponse(videoTranscodeResponse,
transcodeRequest,
String.format("Could not find input file: %s \n%s",
transcodeRequest.getInputURL(), fileNotFoundException));
return; // bail out input file was likely deleted
}
int x = 1/0;
// Get meta for input file
VideoMeta videoMeta = null;
try {
videoMeta = FfmpegMeta.create(workingInputFile);
} catch (IllegalArgumentException illegalArgumentException) {
sendFailedTranscodeResponse(videoTranscodeResponse,
transcodeRequest, illegalArgumentException.toString());
return;
}
if (videoMeta.getVideoCodec().equalsIgnoreCase("mpeg2video")) {
sendFailedTranscodeResponse(videoTranscodeResponse,
transcodeRequest, "Video codec mpeg2video is not supported.");
return; // bail out if unsuppored codecs are found
}
FfmpegCommandBuilder commandBuilder = new
FfmpegCommandBuilder(transcodeRequest, videoMeta, workingInputFile);
for (FfmpegCommand ffmpegCommand : commandBuilder.getCommands()) {
VideoMeta tmpVideoMeta = executeCommand(ffmpegCommand,
videoMeta);
if (tmpVideoMeta != null) {
videoMeta.setDuration(tmpVideoMeta.getDuration());
if (videoTranscodeResponse.getMeta() == null ||
videoTranscodeResponse.getMeta().isEmpty()) {
videoTranscodeResponse.setMeta(videoMeta.serialize());
// use meta from an output
}
}
videoTranscodeResponse.getOutputResults().add(ffmpegCommand.getOutputResult());
}
if (transcodeRequest.getCallBackURL() != null) {
TranscodeResponder.respond(videoTranscodeResponse,
transcodeRequest.getCallBackURL());
}
}
}
} catch (Throwable throwable) {
TranscodeLogger.log(transcodeRequestID, Level.SEVERE,
throwable.toString());
// try {
// if (message.getJMSRedelivered()) {
// TranscodeLogger.log(transcodeRequestID, Level.SEVERE,
"Sending TranscodeRequest to Quarintine.");
// TranscodeRequestQuarantine transcodeRequestQuarantine = new
TranscodeRequestQuarantine();
//
transcodeRequestQuarantine.setQueueDestination(message.getJMSDestination().toString());
// transcodeRequestQuarantine.setReason(throwable.toString());
//
transcodeRequestQuarantine.setTranscodeRequest(transcodeRequest);
// try {
//
transcodeRequestQuarantine.save(String.format("%s-%s.quarantine", new
Date(), transcodeRequestID));
// } catch (Exception quarantineException) {
// TranscodeLogger.log(transcodeRequestID, Level.SEVERE,
quarantineException.toString());
// }
// } else {
// message.setJMSRedelivered(true);
// messageDrivenContextdc.setRollbackOnly();
// }
// } catch (JMSException ex) {
// TranscodeLogger.log(transcodeRequestID, Level.SEVERE,
ex.toString());
// }
// Send response on failure
} finally {
if (workingInputFile != null && workingInputFile.exists()) {
workingInputFile.delete();
}
}
}
Kenneth Saks wrote:
>
> On Aug 26, 2008, at 10:14 AM, kiran tummala wrote:
>
>> Kenneth,
>>
>> thanks for the suggestion. If we set them, in the class file, can we
>> expect the transaction to rollback upon any exception or do we need
>> to explicitly call the rollback. We are currently having an issue
>> when we explicitly call the rollback, it rollsback and the message
>> never moves to the DMQ.
>
> If you explicitly mark the transaction for rollback (e.g. via
> EJBContext.setRollbackOnly()) the message will keep getting
> redelivered. If the transaction is rolling back as a result of a
> runtime exception thrown from onMessage() you can control the maximum
> number of redelivery attempts by setting the
> EndpointExceptionRedeliveryAttempts property in sun-ejb-jar.xml.
> Details are here :
>
> http://docs.sun.com/app/docs/doc/819-7755/6n9m8u5nc?a=view
>
> There's an example here :
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=2630
>
>>
>>
>> thanks,
>>
>>
>> Kiran
>>
>> Container managed transactions and tx attribute REQUIRED are the
>> defaults in EJB 3.0 so you shouldn't have to configure anything. If
>> you do want to configure them explicitly the easiest way is to use
>> annotations. Just add @TransactionManagement(CONTAINER) at the
>> message driven bean class level and @TransactionAttribute(REQUIRED)
>> to the onMessage method.
>>
>> Kenneth Saks wrote:
>>>
>>> On Aug 25, 2008, at 8:04 PM, kiran tummala wrote:
>>>
>>>> Hi,
>>>>
>>>> We have an Message Driven Bean, It subscribes to a message, and
>>>> based on message needs to transcode a media file. If there is a
>>>> failure in the process, we thrown exceptions and in the exception
>>>> we are explicitly calling rollback of message. We would like the
>>>> container to handle this process and found this material
>>>>
>>>> "Because JMS is a full-fledged transaction resource manager, JMS
>>>> work, such as message consumption, and other transaction work can
>>>> be grouped into one transaction. This means that you can choose to
>>>> make a message-driven bean part of a transaction or not. The
>>>> deployment descriptor transaction attribute, which for a
>>>> message-driven bean can be either Required or NotSupported,
>>>> determines whether or not the bean participates in a transaction.
>>>> (If the message-driven bean participates in a transaction, you must
>>>> also be using container-managed transaction demarcation.)"
>>>>
>>>> We would like to use the deployment descriptor transaction
>>>> attribute and set it to Required, so that container manages the
>>>> transaction. How do we configure this in glassfish.
>>>
>>> Hi Kiran,
>>>
>>> Container managed transactions and tx attribute REQUIRED are the
>>> defaults in EJB 3.0 so you shouldn't have to configure anything. If
>>> you do want to configure them explicitly the easiest way is to use
>>> annotations. Just add @TransactionManagement(CONTAINER) at the
>>> message driven bean class level and @TransactionAttribute(REQUIRED)
>>> to the onMessage method.
>>>
>>>> Do we need to do anything special in Netbeans to achieve this.
>>>>
>>>> thanks,
>>>>
>>>>
>>>> Kiran
>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>