UIM Hub & Robot 7.80 BETA now available

[Anon Anon]

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:

• Now packaged with OpenSSL 1.0.1m (backward compatible with older OpenSSL versions)
• Now supports TLS 1.1 and 1.2 cypher suites
• User tags are automatically copied from robot.cfg to hub.cfg when upgrading to hub 7.80
• Removed ability to set SIDs by PU command line
• Output character limit extended in PU executable
• New option in sendqos executable to allowing sending test messages with custom subjects

 

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:

• http://support.nimsoft.com/downloads/customer/hub780/robot_update.zip
• http://support.nimsoft.com/downloads/customer/hub780/hub.zip
• http://support.nimsoft.com/downloads/customer/hub780/nimsoft-robot.7.80.beta.zip
• http://support.nimsoft.com/downloads/customer/hub780/controller_ReleaseNotes_v7_80.pdf
• http://support.nimsoft.com/downloads/customer/hub780/hub_ReleaseNotes_v7_80.pdf
• http://support.nimsoft.com/downloads/customer/hub780/spooler_ReleaseNotes_v7_80.pdf

 

Jim Cooke, Product Manager, UIM Core Services

[Garin Walsh]

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?

 

-Garin

[michael.diaz]

Michael Diaz (ca technologies - QA engineer for hub and robot)

 

Correct no direct fixes in 7.80.beta for hub and robot to:

• address issues related to making hub routing more reliable or deterministic
• address issues around propagation of security.cfg files

 

Michael Diaz (ca technologies - QA engineer for hub and robot)

[Garin Walsh]

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.

 

-Garin

[michael.diaz]

Michael Diaz (ca technologies - QA engineer for hub and robot)

 

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.

 

Michael Diaz (ca technologies - QA engineer for hub and robot)

[Garin Walsh]

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 [140533975963392] hub: Subscribe to All_to_Proxy@/MergeHC-dom/***001001/hostname.***001001/hub failed (2 - communication error)

Jun  1 08:46:59:473 [140533975963392] 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 [140533063345920] 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.

 

-Garin

[Garin Walsh]

Funny - looks like you can't write a post that includes three 'X' characters in a row. They get replaced with '*'.

 

-Garin

[Garin Walsh]

And it looks like this version leaks file handles like the old ones:

 

Jun  1 09:04:00:733 [140494380107520] 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.

 

-Garin

[michael.diaz]

Michael Diaz (ca technologies - QA engineer for hub and robot)

 

Hi Garin

 

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? 

 

Thanks,

Michael Diaz (ca technologies - QA engineer for hub and robot)

[Garin Walsh]

[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

 

-Garin

[michael.diaz]

Michael Diaz (ca technologies - QA engineer for hub and robot)

Hi Garin,

Thanks for information. 

Michael Diaz (ca technologies - QA engineer for hub and robot)

[michael.diaz]

Michael Diaz (ca technologies - QA engineer for hub and robot)

Hi Garin,

 

I have not been able to reproduce either problem you encountered with “tunnel proxy hub” or max file descriptors.  Here is the setup used:

 

All machines:

• CentOS 6.3
• 7.80.beta

 

UIM Server

• name services to macA

 

Hub Tunnel Server macA

•            2 attach queues:

• macA1
• macA2

•            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

• macB1
• macB2

•            2 get queues to macA1 and macC2

•            cdm installed and generating messages

•            Using internal executable sendqos generating 10 messages/sec

 

Hub Tunnel Client to macC

•            2 attach queues

• macC1
• macC2

•            2 get queues to macA2 and macB2

•            cdm installed and generating messages

•            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?

 

Thanks

 

Michael Diaz (ca technologies - QA engineer for hub and robot)

[Garin Walsh]

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 [140702113380096] 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.

 

-Garin

[michael.diaz]

Michael Diaz (ca technologies - QA engineer for hub and robot)

Hi Garin,

Thanks for the additional details and information.  

Michael Diaz (ca technologies - QA engineer for hub and robot)