Zeus User Community

This warning message indicates that the peer (the remote client) closed the connection when Stingray was not expecting it to (in this case, Stingray was still trying to read the request from the client).

Check the section entitled 'Detailed debugging of connections' in the Stingray user manual

In general, you should not be concerned by this.  The error was almost certainly provoked by the client misbehaving or failing in some way.

regards

Owen

Difficult question - best to raise with Riverbed support to investigate

Hi zeus-users,

Some of you may recall the Zeus 'KnowledgeHub' site, where we (Zeus) posted ideas and examples of how to use Zeus Traffic Manager...

I'm pleased to say that finally, "it's back!".  If you're using Zeus Traffic Manager, or the Riverbed-branded Stingray Traffic Manager (same product, new name), then please check out http://splash.riverbed.com/stingray - the beginning of a new Riverbed-hosted community around each of our products.

Almost all of the old Zeus KnowledgeHub content is there, updated and re-tested against the latest release.  There's a discussion/question forum to raise questions or comments if you wish, and a lot of new internal documentation.

If you have time, check it out, register for an account and then hit the 'Follow' button on the Stingray page, and on any content or users you are interested in.  We'll email you a regular digest of content updates, and you can ask questions or contribute answers.

Any questions/comments - please reply to this thread or email me directly - thanks

Owen

ps.  None of this takes away from the great zeus-users.org community, and I'll continue to keep an eye open and contribute when I can - thank you Karsten for hosting and managing it

Hi Mark,

HTTPS applies to the entire connection, not just the body in the response, so it looks like you've got that part working OK.

It's not common to encrypt the XML response (more common just to SSL-encrypt the entire transaction).  Could you provide an example response, including all of the HTTP response headers, and we will take a look to understand what is going on.

Thanks

Owen

Hi,

Transparent session affinity works by inserting a tracking cookie into the first response (once the load balancing decision has been made and the node selected).  If that cookie is present in subsequent requests, then the request is routed to original node.  It's simple and reliable, but does not work in cases where clients do not support or honor cookies.

J2EE Session Persistence works by locating the J2EE Session ID, which may be found either in the URL or a cookie.  This session ID (and the selected node) is shared across the cluster using a cache (j2ee_cache_size determines the size of the cache).  As Karsten points out, you may need to increase the size of the cache, as the default (2048 entries) is rather small.

If you can replicate the problem, then you can use the request logging to understand what is happening.  There are three relevant values that may be logged:

%F     The favored node for this connection 
%n     Node that was used for the connection 
%N     Node required to handle this connection (because of session persistence) 

If session persistence applies, %N will tell you the persisted node and this should match %n (the selected node) unless that node has failed.  In that case, the failuremode setting of the persistence class will define what the traffic manager does.

%F indicates a weekly-preferred node.  If there is no session persistence selection in effect (for example, it's the first request in the session), then we apply heuristics such as preferring the node that most recently responded to the same URL.  These influence the load balancing decision, but are not mandatory and will be ignored if a different node is strongly favoured by the load balancer.

Best regards

Owen

The counters that you graph are also published through the SOAP API (and SNMP), generally in the API's System.Stats interface.

The functions 'getNodeCurrentConn' and 'getNodeCurrentRequests' will give you the information you require.

regards

Owen

Hi Paul,

This might help?

http://www.php.net/manual/en/soapclient.setlocation.php

I've not tried it, but please let us know if it solves the problem (and I'll update the knowledgehub example if so)

regards

Owen

The URI in the WSDL specification is not a web address; you can't resolve and download it.  Using a 'fake' URI is the usual convention for defining a unique namespace.

If you want to create a SOAP client, then you need to investigate the SOAP library support in your preferred language.  Some SOAP libraries require access to the WSDL file (which you can download from the admin interface - https://zeus:9090/apps/zxtm/help.fcgi?section=Manuals), and some are more lax and infer the WSDL specification (e.g. Perl SOAP::Lite).

There are simple examples for a range of languages on the Zeus community:

    http://www.zeus.com/community/search/list%20running%20virtual%20servers%20using

These examples compare and contrast the approaches used by each language to invoke the same SOAP methods