Thanks Joel you have really been responsive, and it is much appreciated. We finally have success. I went back and read over the javadoc and instituted the IsHostedOnLocalNode and GetNodeThatHostsCall. Once I post my request to the right IP, it came directly on my call and played the announcement, amazing!

I would still like to find out how I can log from the web service portion of the Listener. I tried putting GetUCID.class and several things in the Logger.getLogger method, but it doesn't seem to be logging anywhere. This is in a separate class GetUCID.java in the same MyService package.

@Path("ucid")
public class GetUCID
{
MyCallListener service;
private final Logger logger = Logger.getLogger(MyCallListener.class);

Make sure that you've imported com.avaya.collaboration.util.logger.Logger instead of java.util.logging.Logger. This bit me when I was recently doing automatic imports using Eclipse.

I'm happy to hear that you found a way to get your request to the right server and that it's working for you! Here's a mechanism that might help you streamline things. If you put an interactionID query parameter such as the following on your HTTP URI, the Breeze load balancer will ensure that the request always lands on the right server automatically:

https://<Cluster IP or FQDN>/services/YourServiceName/restOfUri?interactionID=ucidOfYourCall

I haven't been able to get the load balancer working, it seems to just round robin, eventually hitting the right server. I'll test that.

I'm also seeing this occasionally--

Call not found, exception = Call does not belong to TestService-1.1.1.17.0, but I know it does because I see it in the log:

TestService FINE - TestService-1.1.1.17.0 - Call UCID -- 12000001211524241947

There's one other thing you could try with the load balancer. We also have an "affinity" query paramter that allows you to request that a request be steered to a particular Breeze server. There's a chance that you need this query parameter before our custom load balancer code will look at the interactionID parameter. InteractionID overrivdes affinity IP, so you wouldn't even necessarily have to populate a valid Breeze IP address for affinity.

https://<Cluster IP or FQDN>/services/YourServiceName/restOfUri?affinity=10.0.0.10&interactionID=ucidOfYourCall

I don't know what would cause the intermitten "Call does not belong to ..." error. That one may require a ticket to diagnose if it persists.

Looks like it is a setting on the cluster we don't have enabled--

However, stateful snap-ins require affinity of HTTP requests to a particular Avaya Breeze™ server. In these cases, you must enable the session affinity attribute on the Avaya Breeze™ cluster

Confirmed it is unchecked, so that's probably why it isn't working.

Yes, you're probably correct on that. I don't think enabling it would have any adverse effects, so you might give it a shot.