ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexWebSphere Message Broker SupportHTTP Url doesnt come up automatically after deployment

Post new topicReply to topic
HTTP Url doesnt come up automatically after deployment View previous topic :: View next topic
Author Message
magvlvri
PostPosted: Mon Aug 20, 2018 8:26 am Post subject: HTTP Url doesnt come up automatically after deployment Reply with quote

Apprentice

Joined: 07 Nov 2014
Posts: 26

We are running on 9.0.0.5 and we are seeing that some applications at times are facing the below issue.

Application is using HTTPInput and HTTPReply nodes. When the application is deployed successfully to the EG, the HTTP url is not registered with the HTTPS Connector object on the EG.

So, when we do a mqsireportproperties on HTTPSConnector on the EG, the url is not present in the list reported.

However, if we do a stop and start of the application, the url comes up as expected and the issue is not seen there after.

There is no pattern to this issue that we have been able to identify. This happens to certain applications only at certain times.

We are confident that this is not a code issue. I wanted to check if anyone had faced this issue with 9.0.0.5.

We had gone through the fix list from IBM on version 9 all the way to 9.0.0.10 and i dont see any references to this issue in the fix list. Instead of just suggesting to upgrade to latest fix pack available, Let me know if you have any other suggestions. Thanks.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Aug 20, 2018 8:51 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25310
Location: Ohio, USA

Pedantically the HTTPInput node shouldn't come up on the HTTPS connector at all unless you've configured it to do so.

When you say "stop and start the application", you mean the application not the EG itself yes?

magvlvri wrote:
Instead of just suggesting to upgrade to latest fix pack available, Let me know if you have any other suggestions.


Open a PMR. If there's no pattern to when it happens, only affects certain applications and not others similarly configured and can be fixed with a restart then that sounds like software to me.

Someone has to be first to find all the bugs that go in the fix packs and if this doesn't appear in the list for FP10 then it sounds like you're the lucky winner.

I should warn you that IBM's default response will be "upgrade to the latest version" - somewhere in the darkness Dr. Pavlov is punching the air. Be resolute and ask which specific fix you need and if it can be built as an APAR for 9.0.0.5.

Or spin up a test 9.0.0.10 environment, put one of the misbehaving applications in it and show it still has problems.

But it sounds a lot like a bug not an application problem to me. You don't mention OS or OS level but you might want to skim through any IP stack related fixes you're missing there (assuming the OS is as back level as IIB).
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
magvlvri
PostPosted: Mon Aug 20, 2018 8:58 am Post subject: Reply with quote

Apprentice

Joined: 07 Nov 2014
Posts: 26

Yes, HTTP nodes are setup to use HTTPS connections by us as required.

Yes, only individual application restarts is resulting in the url coming back up and not EG restart.

As far as server info goes, below is the mqsiservice output.

We are already starting to work with IBM on this, but wanted to tap into the community to get a head start on this.

mqsiservice <BRKR> -v
BIPmsgs en_US
Console CCSID=1208, ICU CCSID=1208
Default codepage=UTF-8, in ascii=UTF-8
JAVA console codepage name=UTF-8

Install Path = /opt/ibm/mqsi/9.0.0.5
Shared Work Path = NOT_HA_ENABLED_BROKER
Local Work Path = /var/mqsi
Component UUID = fd7f5fc4-2e1d-11e4-82ec-ac1208320000
process id = 6325
queue manager = <QMGR>
MQ installation path = /opt/mqm
pubsub migration = no
fastpath Queue Manager = no
configuration timeout = 600
configuration delay timeout = 600
statistics major interval = 60
ComponentType = Broker
Fixpack capability level = 9.0.0.5 (effective level 9.0.0.5)

BIP8996I: Version: 9005
BIP8997I: Product: IBM Integration Bus
BIP8998I: CMVC Level: S900-FP05
BIP8999I: Build Type: Production, 64 bit, amd64_linux_2

BIP8974I: Component: DFDL-C, Build ID: 20150601-1422, Version: 1.1.1.0 (1.1.1.0), Platform: linux_x86 64-bit, Type: production

BIP8071I: Successful command completion.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Aug 20, 2018 9:03 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25310
Location: Ohio, USA

magvlvri wrote:
Yes, HTTP nodes are setup to use HTTPS connections by us as required.


I thought so; I'm just a pedant.


magvlvri wrote:
We are already starting to work with IBM on this, but wanted to tap into the community to get a head start on this.


Makes sense; I've never heard of or experienced this (which of course proves nothing)

magvlvri wrote:
BIP8974I: Component: DFDL-C, Build ID: 20150601-1422, Version: 1.1.1.0 (1.1.1.0), Platform: linux_x86 64-bit, Type: production


Which Linux distro is this? Do they report any network / IP level bugs? Anything probative in the syslog?
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
magvlvri
PostPosted: Mon Aug 20, 2018 9:52 am Post subject: Reply with quote

Apprentice

Joined: 07 Nov 2014
Posts: 26

Below are the OS details.

LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 6.10 (Santiago)
Release: 6.10
Codename: Santiago

I digged through the /var/log/messages and could not find anything on the applications that are impacted with this issue, after the successful deployment log.

I do a GET on the url expected and i get "Unsupported GET" response in the browser.

Another minor detail i might have missed is this. We are using outdated Jazz build management tool here to do remote deployments to IIB server.

There is a nightly job that triggers deployment of all apps on the server and this is development server. I know its a poor choice but bear with me, its grand fathered and i have not been here long enough to revamp this process.

So, the deployment includes like 30-40 applications. One specific application deploy fails with a code issue, however rest of the application deployments happen successfully. We have validated this using /var/log/messages and also doing the mqsilist of applications using the -d2 parameter to check the timestamp and the bar file actually used to last deploy the app.

We see that this issue is observed whenever the build fails for one odd application, however rest of the apps get deployed just fine.

The applications impacted with this issue is random. When the application is stopped and started, the url comes back up.

We are not sure if this has anything to do with the issue, but wanted to throw it out there, just in case.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexWebSphere Message Broker SupportHTTP Url doesnt come up automatically after deployment
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.