RTC 4.0.3 Server - usage with 3.0.1.1 client
2 answers
Hi,
N-1 compatibility will only allow old clients to work against the newer server. If there are features in the newer client, you won't have them in the old client. For example new client side operational behavior.
If you use older and newer clients together, I would suggest to try not to mix the Eclipse workspaces. E.g. use one Eclipse workspace with 3.x and another with 4.x. I happened to open a workspace for 3.x with 4.x - which worked - but then I was unable to open it with 3.x again. I am not sure what the cause was, just want to suggest to be careful.
N-1 compatibility will only allow old clients to work against the newer server. If there are features in the newer client, you won't have them in the old client. For example new client side operational behavior.
If you use older and newer clients together, I would suggest to try not to mix the Eclipse workspaces. E.g. use one Eclipse workspace with 3.x and another with 4.x. I happened to open a workspace for 3.x with 4.x - which worked - but then I was unable to open it with 3.x again. I am not sure what the cause was, just want to suggest to be careful.
Comments
1 vote
4.0.3 provides new function for limiting the impact on the server of feed polling by the client.
the client will scale back the poll rate if there are no new updates or no event views after a while.
this function is not in the 3.0.1.1 client.
at my prior job, the feed polling impact was 40% of the cpu load on the server and database.
source code access was about 45% and the rest were the miscellaneous functions.
so feed polling is expensive. (this doesn't account for the data traffic impact on the network either, which is not reported in Jazzmon)
AND, if this is talking to a 4.0.3 server, then there is new server side function to enable centralized control of the client poll rates to further tune the impact vs value curve. but only with the 4.0.3 client
the client will scale back the poll rate if there are no new updates or no event views after a while.
this function is not in the 3.0.1.1 client.
at my prior job, the feed polling impact was 40% of the cpu load on the server and database.
source code access was about 45% and the rest were the miscellaneous functions.
so feed polling is expensive. (this doesn't account for the data traffic impact on the network either, which is not reported in Jazzmon)
AND, if this is talking to a 4.0.3 server, then there is new server side function to enable centralized control of the client poll rates to further tune the impact vs value curve. but only with the 4.0.3 client