Vice Admiral Vice Admiral
Vice Admiral
3103 views

Anyone else having issues with 7.1.2.7396 ?

Just noticed on two different conapps shortly after I applied 7.1.2.7396 the EPS out on the containers dropped to 0.  EPS in was normal but nothing out.  Logs on the container show Connection to [loggername] port 443 failed ping test and then a bunch of java exceptions.  I rebooted the entire conapp, no change.  Smart connectors seem find though, just the conapps.

Labels (2)
54 Replies
Vice Admiral Vice Admiral
Vice Admiral

Also seeing [2015-04-22 14:30:07,145][FATAL][default.com.arcsight.agent.loadable.transport.event._AgentCEFFileEventTransport][createNewFile] File [/opt/arcsight/connector_1/current/user/agent/cef/2015-04-22-14-30-07.cef] could not be created!   because there is no cef directory on the conapps.

0 Likes
Vice Admiral Vice Admiral
Vice Admiral

Shortly after I posted this all of my smart connectors started doing the same thing.  It may have something to do with the fact that all of our connectors go to Loggers instead of ESM, dunno, either way we are having to do an emergency rollback since our EPS out on all of our connectors is literally 0.

0 Likes
Absent Member.
Absent Member.

Hi Dustin,

we have the same issue, all connectors was upgraded to 7.1.2 and no Events was send to the Logger, but all Events was send to the ESM Destination. After I make a Rollback to 7.1.1 all Events from the cache was send to the logger. I see in the Log File a error from the WatchDog Thread. It's looks like the connection to the logger will be test with a ping to 443 and this don't work.

0 Likes
Vice Admiral Vice Admiral
Vice Admiral

Well I'm glad it wasnt just me, I was told that nobody else had reported any issues.  The rollback immediately fixed all of my connectors except for 2 of my 6 checkpoint connectors running on conapps that would not downgrade.  I had to manually rename the folders via ssh to get those connectors downgraded and running again.

I guess QA didnt test the new build with connectors registered to logger, just ESM.  I have several bugs created with support about issues\errors on the ESM for the loggers that are sending events to the ESM.  My guess is that the developers are assuming all customers are sending events from the Connectors to the ESM, not from the Connectors to logger, which is why they arent seeing these bugs we are having.  We would have a lot less issues with our ESM if we re-designed it so that the connectors send logs directly to the ESM but we cant because we have to have 2 active DR feeds and 2 standby HA feeds for compliance reasons.

0 Likes
Absent Member.
Absent Member.

Hi,

Did you get a chance to open a ticket with support ? We would like to take a look at the logs and configuration.

-Moehadi

APJ Support

0 Likes
Absent Member.
Absent Member.

Thanks for the heads up, I think this will save a lot of headaches as we were about to test deployment of the new connector.

This is obviously a serious issue that should have been caught in QA - its not exactly subtle, and its effect is about as severe as you can get.

0 Likes
Lieutenant Commander
Lieutenant Commander

Is this issue only in case of ConApp or it persists with the software based connector deployments as well. Has anyone tested, if so please update your observations.

Thanks in advance.

Regards,

Mayur M

0 Likes
Absent Member.
Absent Member.

I have yesterday a Support Session with HP and i upload the log.

We test it with ConApp and software based connector, every time we upgraded a existing connector to 7.1.2 the problem appeared, if we make a fresh installation not.

0 Likes
Lieutenant Commander
Lieutenant Commander

Once this issue occurs, have you tried re-registering the destination OR removing & adding the current Logger destination which I guess it should work.

Thank you.

Regards,

Mayur M

0 Likes
Vice Admiral Vice Admiral
Vice Admiral

    I do not want to sound unappreciative for your responses, I do very much appreciate the fact that you are not only watching but also responding to customer threads on Protect.  

I do wonder if it would not be better for HP to just set this up in their lab and reproduce it themselves instead of having customers create tickets, reproduce, upload logs, test workarounds etc....  I would think it would be much faster and more effective if HP Dev\QA\Support does the investigation\testing rather than relying on the customer to do it for them.  I could understand having the customer reproduce and investigate when the issues are complicated and specific to a customers environment, but this seems like a very simple and easily reproducible scenario that is not customer specific.

Do you agree?

Lieutenant Commander
Lieutenant Commander

Dunstan,

I completely agree with you. HP should be testing various scenarios and stability of the connectors in their lab before releasing the connector upgrades. And also additionally I also think that HP should be starting the concept of Beta and Stable version release which will drastically reduce major issues and also HP would be less dependent on client to detect the issues and report it....

Hope it makes sense.

Regards,

Mayur M

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.