For those of you who can, we would greatly appreciate your Beta testing of the latest UIM Hub and Robot, version 7.80.
The highlights are:
The list of defects fixed in this release are included in the release notes.
Please let us know if we are not explaining the new features and resolved defects in sufficient detail in the Release Notes, or if you have specific suggestion on how to improve the release notes for 7.80.
The downloads for the Hub and Robot can be found here:
Jim Cooke, Product Manager, UIM Core Services
Based on this list I presume that there are no fixes related to making hub routing more reliable or deterministic - especially in environments where there are multiple possible routes to a destination or redundant tunnels? Or any attempt to address the issues around the propagation of security.cfg files?
Michael Diaz (ca technologies - QA engineer for hub and robot)
Correct no direct fixes in 7.80.beta for hub and robot to:
I did apply this to a single test server and on the plus side of things, I noticed no difference in behavior (from my perspective) from 7.70.
This is a tunnel client and it fairly readily connected its tunnels back up to a 7.70 tunnel server.
I have been running my hubs with the ssl mode zero and on this one I changed it to mode 1 per the recommendations in the release notes. Again, there was no outwardly appearing difference in behavior. That's also a good thing at this point in the testing.
The GUI works with admin_console with no changes to PPM which is good though I presume that without an updated PPM, I'm not going to see anything that might have been added that needs UI configuration input. It didn't seem like there would be though based on the release notes.
The "help" link terminates on a "page not found" error which, for beta software, I suppose is OK.
As an aside, one thing that would be helpful to people reviewing such a beta would be a more detailed list of defects, their cause, and suggested method of recreating.
Thank you for the preview though.
Thanks for sharing your results from your test environment and recommendations to the release notes. There were no UI changes, thus you would not see any changes in Admin Console related to the hub and robot. The help link show “page not found,” but once GA release hub and robot are released the help link will point to the updated documentation. Thanks for recommendation on more detailed list of defects and this will be discussed.
I tried this on a "tunnel proxy hub" - one that's both a tunnel client and tunnel server plus running both get and attach queues. Compared to 7.70, 7.80 seems to be a lot more unstable with respect to maintaining queues.
If watched in the hub gui on the queue status tab, under 7.70, all the queues on this sample hub would stay green and connected as long as there was a corresponding active tunnel. And there would only ever be two colors: red or green.
With 7.80, I am frequently seeing the messages:
Jun 1 08:46:59:472  hub: Subscribe to All_to_Proxy@/MergeHC-dom/***001001/hostname.***001001/hub failed (2 - communication error)
Jun 1 08:46:59:473  hub: do_check_getq - failed to establish get route All_from_***001001 from /MergeHC-dom/***001001/hostname.***001001/hub, time used: 30024 ms
Jun 1 08:46:59:473  hub: TSESS-A-1224-1 [***01001] sent 100 '_close' (315 bytes, 0 ms)
The "time used" value of 30024ms is suspicious - that looks like a timeout was reached.
And the queues are mostly red even though the tunnels between the hubs are up and stable.
The queues also seem to sit disconnected much longer - on the order of 10 minutes or so before they connect up again. You can see them cycling though if you sort by "established" column but when red and disconnected they cycle round and round. In 7.70, if a queue disconnected for some reason, usually 30 seconds later when it was rechecked, you'd see is go green again. Doesn't seem to be so in 7.80.
Funny - looks like you can't write a post that includes three 'X' characters in a row. They get replaced with '*'.
And it looks like this version leaks file handles like the old ones:
Jun 1 09:04:00:733  hub: FATAL: CTRL ZZZ002004 caused hub to reach max file descriptors
That's after about 4 minutes of run time.
That makes this a non-starter. No excuse in this day and age with the tools at hand and examples of technology for this sort of issue to exist.
Thanks for the feedback on testing the 7.80.beta and bringing up the problem with “tunnel proxy hub” and queues being unstable; and the max file descriptors. This is being looked into, can you provide information on what OS(es) the hub is running on where you see these problems?
[root@proxy13 hub]# uname -a
Linux proxy13.nimsoft.network.internal 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@proxy13 hub]# cat /etc/issue
CentOS release 6.3 (Final)
Kernel \r on an \m
Thanks for information.
I have not been able to reproduce either problem you encountered with “tunnel proxy hub” or max file descriptors. Here is the setup used:
Hub Tunnel Server macA
• 2 attach queues:
• 2 get queues to macB1 and macC1
• cdm installed and generating messages
• Using internal executable sendqos generating 10 messages/sec
Hub Tunnel Client to macB and is Tunnel Server
• 2 attach queues
• 2 get queues to macA1 and macC2
Hub Tunnel Client to macC
• 2 get queues to macA2 and macB2
• Using internal executable sendqos generating 100 messages/sec
I am seeing about 12 million message per hour being sent between the hubs. Can you please provide detail information on the environment and anything that would help us reproduce the problems?
I did a little more research and it appears that the beta creates slightly more network connections that 7.70 and it was tripping up on the error
Nimsoft : [NP2100003] FATAL Event : Jun 5 01:39:11:649  hub: FATAL: CTRL ***001001 caused hub to reach max file descriptors
I reduced the number of tunnels by 15% and now it seems to be "stable" - varies between 550 and 750 ports allocated across a 6 hour runtime. It is unclear what causes it to consume more.
Thanks for the additional details and information.