Near this idea, I think that the need of multiple processing chains in
Stanbol will appear.
As for example, when upload a document, (at least) two types of
processing chain could be useful :
- The first one - fast - with just one or two "essentials" engines,
provide entities to the users in (near) "real time"
- The second one - slower -with a lot of engines, provided a detailed
analysis, and computations that help for classification, summary,
detailed enhancements, etc... and are displayed to the user later or
when reopen document.
As I know, for now, the only way to do that is to set up two different
Stanbol servers, with a different engine stack for each...
An opportunity to define different processing chain is something in the
roadmap ?
++
On 07/06/2011 11:54 PM, Ezequiel Foncubierta wrote:
Hi,
I'm not sure if this option is currently supported or there is a plan to do it.
I think that would be interesting to enable an async option when you call the
engines/ resource. If the system is overloaded, or some engines take a long
time to process the content, it should be an option to run asynchronous
transactions. Some integrations requires synchronous calls, because they want
to tag contents in the same transactions. But, could be some others in which
the synchronous calls are not a required feature.
This proposal is because, almost the all the current integration uses
synchronous calls. It means that, the content creation process is as following:
1. Create the content in the CMS
2. Send the content to the enhancer
3. Write the enhancer results
4. Relate the content with the extracted entities
So, the CMS performance depends on the Apache Stanbol performance. An
alternative, would be creating the content and run a background process to
extract the enhancements (using different transactions).
A first way to get it, is by sending a url parameter (e.g.
referer=http://system/listener/service). If this parameter is present, then run
the enhancements in a background thread and, once finished, then send the
results to the specified url in the referer parameter.
You know better than me the pros and cons of the current implementation, so...
what do you think about the asynchronous calls?
Thanks. Regards,
--
Ezequiel Foncubierta
This message should be regarded as confidential. If you have received this
email in error please notify the sender and destroy it immediately. Statements
of intent shall only become binding when confirmed in hard copy by an
authorised signatory.
Zaizi Ltd is registered in England and Wales with the registration number
6440931. The Registered Office is 203 Westbourne Studios, 242 Acklam Road,
London W10 5JJ, UK.
