Archived

This forum has been archived. Please start a new discussion on GitHub.

Glacier2 forwarding policy problems

I've played around with setting up forwarding policies for my proxies, but I encountered a couple of problems, presumably because I don't understand the system well enough.

The main issue is that I have a number of push updates from server to client, that are send as oneway messages, and thus should logically be forwarded as oneway requests as well. But if I add _fwd=O to the default context of my server, the client never gets these pushed updates. I can see the calls in the Glacier2 trace, but they never seem to reach the client. Glacier isn't reporting any errors.

If I set the server side forwarding policy to _fwd=t explicitly (This is the default policy as far as I could see) the calls do get through, but now they no longer seem to appear in my Glacier2 traces.

I was also unsure where I was actually supposed to set the forwarding policy. The proxy which is used to push the updates is created on the client and then send to the server. So would it be possible to set the forwarding policy when the proxy is created on the client, or does it have to be set serverside? Basically I'm wondering if a default context on a proxy is transmitted when the proxy is transmitted.

I haven't investigated this very deeply, as it isn't a terribly high priority right now, but if I'm doing something obviously wrong, a hint would be appreciated.

Comments

  • Forget this, I think most of my current problems are adequately explained by the fact that I had accidentally configured an endpoint for my client.
  • benoit
    benoit Rennes, France
    I've played around with setting up forwarding policies for my proxies, but I encountered a couple of problems, presumably because I don't understand the system well enough.

    The main issue is that I have a number of push updates from server to client, that are send as oneway messages, and thus should logically be forwarded as oneway requests as well. But if I add _fwd=O to the default context of my server, the client never gets these pushed updates. I can see the calls in the Glacier2 trace, but they never seem to reach the client. Glacier isn't reporting any errors.

    I can't think of any reasons why this wouldn't work. If you use the buffered mode and correctly set the _fwd=O context on the proxy in the server, Glacier2 should forward the oneways in batches.
    If I set the server side forwarding policy to _fwd=t explicitly (This is the default policy as far as I could see) the calls do get through, but now they no longer seem to appear in my Glacier2 traces.

    They should appear in the Glacier2 traces, if they don't this means that the calls are sent directly to the client. See the other post ;), you could enable network tracing on the server to ensure that your server is only establishing connections to Glacier2, not to your clients.
    I was also unsure where I was actually supposed to set the forwarding policy. The proxy which is used to push the updates is created on the client and then send to the server. So would it be possible to set the forwarding policy when the proxy is created on the client, or does it have to be set serverside? Basically I'm wondering if a default context on a proxy is transmitted when the proxy is transmitted.

    I haven't investigated this very deeply, as it isn't a terribly high priority right now, but if I'm doing something obviously wrong, a hint would be appreciated.

    No, you can't set it in the client, the default context isn't transmitted over the wire with the proxy. Setting it in the client would be wrong anyway since a rogue client could change the default forwarding policy. You should set it in the server. If your server only makes invocations on clients (through Glacier2) the easiest is probably to set the default context on the communicator, otherwise, you should set the default context for each proxy from the client.

    Cheers,
    Benoit.
  • Yup. Cleaning up the endpoint settings in my client helped me to resolve alle the other problems. As far as I can tell from the logs I am now using oneway batched dispatch in my push updates, just as I wanted.