Some very valuable information is surfacing, thanks. More questions/feedback--
On 5/28/06, John Mettraux <
[EMAIL PROTECTED]> wrote:
That would be excellent. I don't know if Mustang (Java 1.6) has better classloading functionality or whether there
is some trickery you've already imagined.
Well, the java-agent isn't reading the store directly. What I'm doing is having the python agent that is a cron services at the engine level check to see how many workitems are already in that java-agent's store (alpha). A kind of throttle on the workload to make sure
that fileid-java-agent's queue doesn't fill up faster than it can get rid of workitems (this would happen).
Even so, I thought that to route a workitem to an apre agent or other participant there had to be a store associated with it.
This poses an interesting problem for me. How can I throttle things if I can't query a store
to see how many workitems are in a participants's queue, particularly an apre participant?
My python agent will be producing things faster than the fileid-java-agent can process them.
If a bunch of workitems are sent to an apre agent, but that agent spends a long time in use(),
where are those unprocessed work items stored in the interim? I thought it was the stores.
I switched the order but it didn't eliminate the WARN ...
Thanks,
Tony
> > > One specific question: Can an agent class reside in a .jar that's in
> > > ./apre-scripts/ (agentPath) or do jars need to be unpacked?
> >
> > Agents classes must be on the agent classpath. If you want to put them
> > in apre-scripts/, the jar will need to be unpacked.
>
> Ok, sounds like a feature request is in order. For classes that
> depend on third party libraries involving other .jars, unpacking all
> of them might be cumbersome.
We should think about saying something like : place your java agents
jar within the apre-scripts/jars/ directory and they'll automatically
be available to the APRE.
What do you think ?
That would be excellent. I don't know if Mustang (Java 1.6) has better classloading functionality or whether there
is some trickery you've already imagined.
> As a diagnostic technique, I did a search for all specifications of
> the agent's name and found that I 2 of the 4 did match the other 2. I
> corrected this and now the agent executes.
>
> So would recommend the following (unix) technique as one potential
> best practice for users to confirm accuracy and integrity of .xml
> files.
>
> $ find . -name '*.xml' | xargs egrep 'fileid-java-agent'
> ./etc/apre/agents.xml: name="fileid-java-agent"
> ./etc/worklist/passwd.xml: <principal
> password="+84+10+19-102+123-96+94+50+65+84+118-49-126-36-2-49"
> class="openwfe.org.auth.BasicPrincipal" name="fileid-java-agent">
> ./etc/worklist/worklist-configuration.xml:
> <param-value>role-alpha, notif-alpha, fileid-java-agent</param-value>
> ./workflow-definitions/fileid_flow_1.0.xml: <participant
> ref="fileid-java-agent" />
You don't need to register a principal for you "fileid-java-agent"
participant within etc/worklist/passwd.xml, principals are worklist
users, not [automatic] participants (or am I wrong : you seem to have
a store that your agent is able to read...)
Well, the java-agent isn't reading the store directly. What I'm doing is having the python agent that is a cron services at the engine level check to see how many workitems are already in that java-agent's store (alpha). A kind of throttle on the workload to make sure
that fileid-java-agent's queue doesn't fill up faster than it can get rid of workitems (this would happen).
Even so, I thought that to route a workitem to an apre agent or other participant there had to be a store associated with it.
> I have found the third one (the association of the agent with the
> store) easy to forget.
It's not necessary to have a store for an agent. The store will never
get used. And, out of the box, OpenWFE's participant map routes all
workitem for participant whose name ends with '-agent' to the java
APRE.
This poses an interesting problem for me. How can I throttle things if I can't query a store
to see how many workitems are in a participants's queue, particularly an apre participant?
My python agent will be producing things faster than the fileid-java-agent can process them.
If a bunch of workitems are sent to an apre agent, but that agent spends a long time in use(),
where are those unprocessed work items stored in the interim? I thought it was the stores.
> I still see this in engine.log:
> 2006-05-27 22:25:02,207 [main] WARN
> openwfe.org.engine.impl.participants.CompositeParticipantMap -
> lookupFactories() no ParticipantMapFactory named 'xmlPmapFactory'
> found.
>
> But now I only see it once (at startup).
OK, that's great, it means that at startup it doesn't find the
factory, as its the service that gets initialized next. By placing the
factory configuration before the pmap service itself, you won't have
this message anymore.
I switched the order but it didn't eliminate the WARN ...
Thanks,
Tony
