Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [smila-user] JMS broker configuration for multiple machines 
Hi Giorgio,

first, the default RecordFilter setting ("nothing") should be ok for you.
Here's a link to the documentation, with a commented example of different filters:
http://wiki.eclipse.org/SMILA/Documentation/QueueWorker#RecordFilter

Your other problems are a little bit hard to "debug" from remote. ;)
But, you said that everything works fine when using only one machine, right?
If that's correct, then from my experience everything should also work on such a distributed environment. Because the whole BPEL processing is equal to a local szenario, in your case even the Queue is on the same machine (Marty).

First you should check, if configuration file changes (e.g. those describing your own pipelines, pipelets, index) were distributed to both machines, above all to the processing one (Marty).

If you still run into problems, please re-check if your szenario is really running on a single machine without problems.

Other shots in the dark:
- In the QueueWorkerListenerConfig.xml, try to set "Threads" and "MaxMessageBlockSize" to "1".
- Which platform are you using? Could the error message below come from a rights problem, to not be able to create a new index directory with the current user?

What you also could do is to check if the standard configuration works in your distributed Indy/Marty szenario by changing only those configuration files we discussed before. The way to run the standard example is described here: http://wiki.eclipse.org/SMILA/Documentation_for_5_Minutes_to_Success

Hope this helps,
 Andreas

> -----Ursprüngliche Nachricht-----
> Von: smila-user-bounces@xxxxxxxxxxx [mailto:smila-user-bounces@xxxxxxxxxxx] Im Auftrag von Giorgio
> Sironi
> Gesendet: Freitag, 9. April 2010 12:22
> An: Smila project user mailing list
> Betreff: Re: [smila-user] JMS broker configuration for multiple machines
> 
> On Fri, Apr 9, 2010 at 9:36 AM,  <Andreas.Weber@xxxxxxxxxxx> wrote:
> > First, you don't need a JMS Broker (a Queue) on host Indy at all, because you won't need Queues
> there.
> > (But it also doesn't matter if one is started here for localhost, so leave JMS.properties as they
> are)
> 
> So the jms.properties is used only to start a server and all the
> client components are not affected by it. Ok.
> 
> > So you are right - Indy Listener is stealing messages from the queue.
> > To solve this, just edit the QueueWorkerListenerConfig.xml on Indy, and e.g. remove or comment out
> the <Rule> that is contained there.
> 
> I commented out all the Rules and now I see Marty is processing the .
> However I ran into other problems:
> - the QueueWorkerRouterConfig.xml has a RecordFilter attribute in its
> Send task. I saw that Marty was complaining about missing attributes,
> so I substituted "nothing" with "no-filter" (I found those values in
> the blackboard configuration.) How did it work in local if the
> attributes were all stripped out?
> - then I had to comment out from the add pipeline my pipelets and
> services, as it says they are not loaded. This may be some
> side-effect, but they were working in local.
> - after some processing, the BPEL executor starts throwing some
> exception. The first is:
>  2010-04-09 11:39:52,944 ERROR [ODEServerImpl-1
>       ]  lucene.LuceneIndexService                     - error
> processing record
> src:file|key:<Path=/home/giorgio/smila_sample_indy/science.u8.txt>
> org.eclipse.smila.search.index.IndexException: java.io.IOException:
> cannot read directory
> org.apache.lucene.store.FSDirectory@/opt/smila/workspace/.metadata/.plugins/org.eclipse.smila.lucene/t
> est_index:
> list() returned null
>     at
> org.eclipse.smila.search.lucene.index.access.IndexWriterPool.flushIndexWriter(IndexWriterPool.java:117
> )
>     at org.eclipse.smila.search.lucene.index.IndexConnection.flushIndex(IndexConnection.java:333)
>     at
> org.eclipse.smila.search.lucene.index.IndexConnection.writeDocumentToIndex(IndexConnection.java:322)
>     at org.eclipse.smila.search.lucene.index.IndexConnection.learnDocument(IndexConnection.java:304)
>     at org.eclipse.smila.lucene.LuceneIndexService.addRecord(LuceneIndexService.java:263)
>     at org.eclipse.smila.lucene.LuceneIndexService.process(LuceneIndexService.java:192)
>     at
> org.eclipse.smila.processing.bpel.ProcessingServiceManager.doInvoke(ProcessingServiceManager.java:150)
>     at org.eclipse.smila.processing.bpel.ExtensionManager.invokeAdapter(ExtensionManager.java:228)
>     at org.eclipse.smila.processing.bpel.ExtensionManager.invokeActivity(ExtensionManager.java:164)
>     at
> org.eclipse.smila.processing.bpel.SMILAExtensionBundle$InvokeServiceActivity.run(SMILAExtensionBundle.
> java:126)
>     at
> org.eclipse.smila.processing.bpel.SMILAExtensionBundle$InvokeServiceActivity.run(SMILAExtensionBundle.
> java:138)
>     at org.apache.ode.bpel.rtrep.v2.EXTENSIONACTIVITY.run(EXTENSIONACTIVITY.java:62)
>     at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
> And then many others, like 'too many open files'. I guess it's trying
> to process all JMS messages at once and it's too much to handle?
> Thanks for any support.
> 
> Regards,
> --
> Giorgio Sironi
> Piccolo Principe & Web Engineer
> http://giorgiosironi.blogspot.com
> http://twitter.com/giorgiosironi
> _______________________________________________
> smila-user mailing list
> smila-user@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-user

Back to the top