AMI question

[stephan]

Just a quick question on AMI.

When I have subsequent proxy calls, i.e. if I call a proxy (synchronously) with the respective servant then doing an AMI call to another proxy, is there anything to be taken into account? Unfortunately I did not have luck to implement this yet so I wanted to ask if there are pitfalls to find, the code of the first servant looks like this:

The definition:

interface Action
{
["ami"] void perform();
}

interface ActionProcessor
{
void process();
}


The implementation:

public class AMI_I_MyCall : AMI_MyCall
{
void ice_response()
{
pParent->m_bDone = true;
}
}

public override void process(Ice.Current current)
{
bDone = false;

AMI_I_MyCall cb = new AMI_I_MyCall();

action.perform(cb);

while (!bDone)
{
// do something else
}
}


I hope that this example shows what I mean. Is using AMI in this case the optimal solution or are there better ones?

Kind regards,

Stephan

[benoit]

Assuming that bDone and m_bDone are the same attributes and that you will add proper synchronization, I can't see anything wrong with your example (the call to action perform would be action.perform_async(cb); though).

Benoit.

[stephan]

Originally Posted by benoit

Assuming that bDone and m_bDone are the same attributes and that you will add proper synchronization, I can't see anything wrong with your example (the call to action perform would be action.perform_async(cb); though).

Yes, you are right. These were typos. I'll check out if I can gather further information and post that later.

What I'm aiming at is to create a little workflow engine and the loop I wrote down basically is the state machine processor. The action class are derived into more special actions (start, end, decision, wait for file, send message and wait for user reply, copy file, convert data etc.).

Is AMI a viable technique for this purpose? Or would oneway invocations be better? AMI somehow limits scalability (due to thread assignment) but oneway is not as safe...

Stephan

[benoit]

I wouldn't use oneway since it's not as reliable as twoway calls. It's difficult to say if using AMI is the right choice here without knowing a bit more about your application. But it's not clear to me what your concerns are with respect to scalability, what do you mean by the "thread assignment"? Can you clarify this?

Benoit.

[stephan]

Hi again,

sorry, I still do not manage to get the program working. I attached my entire workspace to this posting and hope that you can try it out (please modify the config.txt files in the debug directories with your host info). Then start server, then the client (as usual).

A process will be created on the client side and then be invoked using tempIterate(). In the tempIterate() implementation, perform() should be called using AMI but apparently, it is never called for some reason.

Please let me know if I can help with some additional comments.

regs,

Stephan

P.S.: Please notice that I didn't install the slice2cs patch yet, so I'm using some workarounds around the collection bug.
P.P.S.: Will the AMI section for C# be improved for Ice 2.1? It's a bit awkward to read, the example doesn't help too much

[benoit]

By default the Ice server thread pool has only one thread. Can you try to increase the server thread pool? I suspect this is the problem. The AMI call perform() can't be dispatched because there's no more threads available in the thread pool. To increase the server thread pool, you can use the Ice.ThreadPool.Server.Size property or the Ice.ThreadPool.Server.SizeMax property (see the Ice manual for details on these properties).

Let us know if this doesn't help!

Benoit.

[stephan]

bingo. That was it. So easy... is that different to C++? IIRC, I never had this problem there.

Anyway, thanks for helping so quickly!

[benoit]

I'm glad it works now! It's the same for C++ and Java since Ice 1.3.0 (previous versions had different defaults settings for the thread pool sizes).

Benoit.