We have the JMS Messaging Modular Input configured for WebSphere MQ topic. We are not allowed to use client mode to connect to the queue manager for security reasons. Could you please help me with a sample stanza in inputs.conf and required jars to ensure the app uses binding mode to connect to the queue manager that is local to it. JMS modular input and Qmgr are on the same m/c.
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | The native library 'mqjbnd' is used by the WebSphere MQ classes for
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | Java and WebSphere MQ classes for JMS when creating a connection to
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | the queue manager using a 'bindings' mode connection. A bindings
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | mode connection is a connection which uses the system's memory to
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | communicate with the queue manager, as opposed to a 'client' mode
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | connection which uses a TCP/IP socket.
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" |
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | In order to communicate with a queue manager using a bindings mode
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | connection, the queue manager must be located on the same system as
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | the WebSphere MQ classes for Java/JMS. If this is not the case in
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | your environment, consider reconfiguring the application to utilise
08-01-2016 12:55:50.530 +0200 ERROR ExecProcessor - message from "python /opt/splunkforwarder/etc/apps/jms_ta/bin/jms.py" | client mode connections.
Thank u so much.
I believe the transport mode(client or bindings) is declared in MQ when you are setting up JMS and generating your bindings file.
thanks Damien, we got it working for queue. However to directly subscribe to a topic, it doesn't seem to work.
Is this stanza below correct for topic config
also what should the source type be for topic? For queue it was mq.
jms://topic/LOGEVENT.TOPIC
browse_mode = stats
browse_queue_only = 0
durable = 0
host = klc41101
hec_batch_mode = 0
hec_https = 0
index_message_header = 0
index_message_properties = 0
init_mode = jndi
jms_connection_factory_name = TCF_QTIIB01
jndi_initialcontext_factory = com.sun.jndi.fscontext.RefFSContextFactory
jndi_provider_url = file:///var/mqsi/custom/jndi
output_type = stdout
strip_newlines = 1
client_id = CLIENTID
sourcetype = mq
index = linux_iib_app
disabled = false
thank you
1) Did you read and attempt to try what I posted in my answer above regarding setting up your bindings file ? There is nothing you need to change in inputs.conf as far as I am aware.
2) "It doesn't seem to work" is generally of no use to folks trying to diagnose an issue. Are there any log messages that show that ACTUAL error. Search string : index=_internal ExecProcessor error jms.py
1) Yes we did set it at MQ level TRANSPORT(BIND). Those entries in JMS TA logs about client mode seems like info and not really error. The had’nt worked earlier coz the index on splunk was not enabled.
2) For topics, below is the TCF and T configured in MQ JMS:
InitCtx> dis tcf(TCF_QTIIB01)
ASYNCEXCEPTION(ALL)
BROKERCCSUBQ(SYSTEM.JMS.ND.CC.SUBSCRIBER.QUEUE)
BROKERCONQ(SYSTEM.BROKER.CONTROL.QUEUE)
BROKERPUBQ(SYSTEM.BROKER.DEFAULT.STREAM)
BROKERQMGR()
BROKERSUBQ(SYSTEM.JMS.ND.SUBSCRIBER.QUEUE)
BROKERVER(UNSPECIFIED)
CLEANUP(SAFE)
CLEANUPINT(3600000)
CLIENTID(splunk)
CLONESUPP(DISABLED)
COMPHDR(NONE )
COMPMSG(NONE )
CONNOPT(STANDARD)
FAILIFQUIESCE(YES)
MAPNAMESTYLE(STANDARD)
MSGBATCHSZ(10)
MSGSELECTION(CLIENT)
OPTIMISTICPUBLICATION(NO)
OUTCOMENOTIFICATION(YES)
POLLINGINT(5000)
PROCESSDURATION(UNKNOWN)
PROVIDERVERSION(UNSPECIFIED)
PUBACKINT(25)
QMANAGER(QTIIB01)
RECEIVEISOLATION(COMMITTED)
RESCANINT(5000)
SENDCHECKCOUNT(0)
SHARECONVALLOWED(YES)
SPARSESUBS(NO)
STATREFRESHINT(60000)
SUBSTORE(BROKER)
SYNCPOINTALLGETS(NO)
TARGCLIENTMATCHING(YES)
TEMPTOPICPREFIX()
TRANSPORT(BIND)
USECONNPOOLING(YES)
VERSION(7)
WILDCARDFORMAT(TOPIC_ONLY)
InitCtx> dis t(COMMONEVENT.TOPIC)
BROKERCCDURSUBQ(SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE)
BROKERDURSUBQ(SYSTEM.JMS.D.SUBSCRIBER.QUEUE)
BROKERPUBQ()
BROKERPUBQMGR()
BROKERVER(V1)
CCSID(1208)
ENCODING(NATIVE)
EXPIRY(APP)
FAILIFQUIESCE(YES)
MDMSGCTX(DEFAULT)
MDREAD(NO)
MDWRITE(NO)
MSGBODY(UNSPECIFIED)
MULTICAST(ASCF)
PERSISTENCE(APP)
PRIORITY(APP)
PUTASYNCALLOWED(AS_DEST)
READAHEADALLOWED(AS_DEST)
READAHEADCLOSEPOLICY(DELIVER_ALL)
RECEIVECCSID(1208)
RECEIVECONVERSION(CLIENT_MSG)
REPLYTOSTYLE(DEFAULT)
TARGCLIENT(JMS)
TOPIC(COMMONEVENT.TOPIC)
VERSION(7)
WILDCARDFORMAT(TOPIC_ONLY)
and in native MQ for the QMgr the topic was created
DEFINE TOPIC('COMMONEVENT.TOPIC')
TOPICSTR('$SYS/Broker/BQTIIB01/Monitoring/#')
and below is the stanza in inputs.conf
[jms://topic/:COMMONEVENT.TOPIC]
browse_mode = stats
browse_queue_only = 0
durable = 0
hec_batch_mode = 0
hec_https = 0
index_message_header = 1
index_message_properties = 1
init_mode = jndi
jms_connection_factory_name = TCF_QTIIB01
jndi_initialcontext_factory = com.sun.jndi.fscontext.RefFSContextFactory
jndi_provider_url = file:///var/mqsi/custom/jndi
output_type = stdout
sourcetype = jms
strip_newlines = 1
logs seem normal
127.0.0.1 - splunk-system-user [05/Aug/2016:15:30:29.138 +0200] "GET /servicesNS/nobody/jms_ta/data/inputs/jms/topic%252F%3ACOMMONEVENT.TOPIC HTTP/1.1" 200 7088 - - - 9ms
127.0.0.1 - splunk-system-user [05/Aug/2016:15:30:29.125 +0200] "GET /services/data/inputs/jms?count=-1 HTTP/1.1" 200 4840 - - - 11ms
127.0.0.1 - splunk-system-user [05/Aug/2016:15:30:19.068 +0200] "GET /servicesNS/nobody/jms_ta/data/inputs/jms/topic%252F%3ACOMMONEVENT.TOPIC HTTP/1.1" 200 7088 - - - 9ms
127.0.0.1 - splunk-system-user [05/Aug/2016:15:30:19.054 +0200] "GET /services/data/inputs/jms?count=-1 HTTP/1.1" 200 4840 - - - 10ms
We still don't get the messages into splunk, though! what are we missing? For the queue configured in MQ to subscribe to the same topic, it works perfectly fine. But directly from topic (JMS) it does not!
PS: Does client id matter? at the TCF it is set to splunk, shud we set it to splunk in the stanza too?
Thank you
It worked. The topic attribute on JMS Destination had to be the topic string and not the topic name.
TOPIC(COMMONEVENT.TOPIC) this had to be changed to the string.
Thanks