Blocking Servlet- long operation - Best solution

Hello -

We run teamsite 7.3.1 on redhat.

I have a requirement to generate 50 different images with different aspect ratios of an asset that's in Media Bin.
The 50 different images will be saved in teamsite.

I'm implementing this as follows
- Open a DCT
- Browse to MediaBin and select asset
- Save XML (DCR). Now this contains the asset id of the asset
- Kick off a workflow
- Use URLExternalTask that'll use a Webservice client to interact with MediaBin WebService (all Java).
- Generate all 50 versions and save them in teamsite.

URLExternalTask, ultimately invokes a servlet if I understand it right.
Each call to MediaBin WebService is a blocking call.
As a result calling the websvc 50 times can take a long time (1 minute or more).

So running this inside a servlet container is not the best approach.

It seems like teamsite runs jboss container.

Is there a way to implement asynchronous servlets in teamsite?

Alternately I could just use externaltask or CGITask to avoid the whole thing I guess.

Thanks
A

Find more posts tagged with

Comments

Rick Poulin

As a result calling the websvc 50 times can take a long time (1 minute or more).

Why is this an issue? If you're using a URLExternalTask, then you want this to be a server-side process (which is a good idea), so what does it matter if it doesn't complete in less than a minute? I've seen external tasks run for a half hour before.

So running this inside a servlet container is not the best approach.

Why not? It feels like you have some other requirement that isn't mentioned in your post.

Is there a way to implement asynchronous servlets in teamsite?

No, because the servlet API used by TeamSite isn't up to that version yet. However, you can make your servlet asynchronous by forking a Thread for the main execution and then returning... but I don't get why this is needed in your scenario.

Alternately I could just use externaltask or CGITask to avoid the whole thing I guess.

How does that help you at all?

Jashan

My task may potentially take 2 hours to complete in the future.

I'm trying to stick to best practices.
Like blocking a Servlet instance for extended times, blocks the container thread calling it. Depending on server configuration and other aspects, the blocking call, may prevent some users from receiving responses from the container etc.

CGITask (or ExternalTask) helps me because, it'll run as a separate process outside a container, which allows me to "block" for long times - 30 mins or 2 or 4 hrs etc.

Thanks
A

Rick Poulin

If you're using URLExternalTask the way you're supposed to (i.e. URL=/iw-cc/urlexternaltask and wf var ClassName=com.mycompany.MyCustomClass), then the urlexternaltask handler should fork your MyCustomClass in a separate thread and allow the calling workflow to close the URL connection. As such, your container's available Socket pool should be free to handle more requests and your users are none the wiser. If you have reason to suspect this is not the case on your version of TeamSite (or you're using a full-on custom servlet), there's nothing preventing you from forking your own Java thread in the execute() call of your class, to make sure that you close off whatever callstack used by the urlexternaltask dispatch, but you shouldn't have to.

CGI/External tasks don't help you at all here. Yes, they explicitly fork off separate processes instead of separate Java threads, but the thread doing the calling will still sit there and wait for the child process to complete before returning. For CGI tasks, that caller is the user's browser -- so it doesn't lock up a thread in the workflow engine, but it still locks up a Socket to your container. In this model, you're essentially *forced* to have your other process fork off something asynchronous so that the workflow call can return in a timely manner. It's possible that iwov has used the same magic on External tasks, but 1) there's no advantage here over URL tasks, and 2) this is for sure not the case with a CGI task.