Search FAQs

Print

NASTEL.APTM.MESSAGE Queue became full and not draining

Written by Oleg Ustoyev. Posted in TransactionWorks FAQs

PROBLEM:

The NASTEL.APTM.MESSAGE queue reaches its maximum queue depth. The queue became full. After recycling  nsqtacon, the queue was quickly drained.

SOLUTION:

The TransactionWorks probe exit captures messages passing through and places them in this queue based on queues selected for processing. The process nsqtacon reads the messages off this queue and sends the data via TCP to the transaction analyzer. During peaks of activity in MQ, this queue will have messages in it. 

It should only be considered a problem if the queue is not open for input and messages are not getting processed. 

If messages are being processed but not fast enough, perhaps due to latency with the transaction analyzer, increase the number of threads being used by nsqtacon (-T parameter). This will increase the number of messages per second that it can process and send. 

The transaction analyzer probe statistics can be used to get the volume of messages processed and the most recent messages.

Print

Purge failed with java.sql.SQLException: ORA-01418: specified index does not exist

Written by Arthur Abramov. Posted in TransactionWorks FAQs

Running purge for  got below error. Could you please advise on this.

 

 BUILD FAILED

 

/opt/nastel/AutoPilotM6/sql-scripts/tworks/tworks_dbmaint.xml:167:
java.sql.SQLException: ORA-01418: specified index does not exist
ORA-06512: at "NASTEL2.TWSP_REBUILD_TRAN_INDEXES", line 27
ORA-06512: at "NASTEL2.TWSP_PURGE_TRANS_BACKGROUND", line 182

======================================================================

 

 Cause:  This indicate a missing index on the tw_messages tables.   It should exist as we do not remove it during normal maintenance.   Please verify the following indexes

 

 SELECT index_name FROM user_indexes WHERE UPPER(index_name) LIKE 'TW_MESSAGE%'

 

 Also, please rung the following so we can confirm which schema version you are using select * from twadm_version;

 

 

Solution: 

To rebuild the missing index, please do the following

CREATE INDEX tw_messages_value_idx ON tw_messages(msg_value) INITRANS 32 NOLOGGING;                           

 

Then we need to rerun the step to recreate the indexes. To recreate the indexes execute:

 

call twsp_remove_tran_indexes();  

call TWSP_REBUILD_TRAN_INDEXES();

When the rebuild index completes, you can restart the transactions analyzer. There is no need to run purge again since the purge completed, the only step that didn't was rebuilding the indexes.

 

 

 

Print

Should I run Create, Upgrade or Reload procedures after applying update nn

Written by Richard Nikula. Posted in TransactionWorks FAQs

You should only run Create (or re-create) once.   If you run it again, it will delete all data including any configuration that you have done.   If you want to re-create the data but leave the configuration, use Update with Purge.

When applying a new Transaction Analyzer, you should upgrade the database to match.  You can always choose the Update option - it will figure out if you need to apply a given update file or not and skips any updates already applied.   

With the upgrade option, you can also choose to remove any existing data.   This is quicker than purging all data as it simple truncates the data from the tables.   As noted above, the key thing is that it leaves the configuration data as is.   


The Load Procedures option is used when applying a patch version.  If you have the latest schema version applied, than this skips them.  This is primarily done when getting a fix pack that only contains changes to the stored procedures.   Upgrade also loads the latest stored procedures so when in doubt, use Upgrade not Reload stored procedures.

Print

When I run the Datapower Direct feed probe in Autopilot server getting Connection refused error

Written by Arthur Abramov. Posted in TransactionWorks FAQs

When runnning the Datapower Direct feed probe in Autopilot M6 server, getting the exception below

Command :  java -jar tworks-feed-probe.jar -f:/opt/nastel/AutoPilotM6/directfeed/config/tw-direct-feed-probe.xml &

Below is the error

2016-06-28 05:36:34,806 ERROR [8:WmqFeeder:WmqFeeder!WmqFeeder] - Failed to connect to tcp://localhost:6400/ [^]

java.net.ConnectException: Connection refused

        at java.net.PlainSocketImpl.socketConnect(Native Method)

        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)

        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)

        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)

        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

        at java.net.Socket.connect(Socket.java:579)

        at java.net.Socket.connect(Socket.java:528)

        at java.net.Socket.<init>(Socket.java:425)

        at java.net.Socket.<init>(Socket.java:208)

        at com.nastel.janus.net.tcp.TcpClient.connect(TcpClient.java:81)

        at com.nastel.janus.probeapi.net.AnalyzerGateway.open(AnalyzerGateway.java:188)

        at com.nastel.janus.probe.directfeed.feeders.ActivityFeeder.run(ActivityFeeder.java:526)

        at java.lang.Thread.run(Thread.java:745)

2016-06-28 05:36:34,807 INFO [8:WmqFeeder:WmqFeeder!WmqFeeder] - Will retry in 15 seconds

Solution: Try  "telnet localhost 6400" to verify the connection is correct. If you are able to connect, verify that the Transaction Analyzer is running on this server and specified to use port 6400

 

Print

Why queue appears in the transaction trace if its not in the stitching rules

Written by Arthur Abramov. Posted in TransactionWorks FAQs

Nastel Tworks track the message in any queue it goes through, the options only control which queues we extract tokens from.   You might have the common one at the end –f * which applies to every queue.   If you don’t want to see a queue, you have to exclude it either in nsqtacon options or TA exclude options.   But if the queue is included and the message passes through it, we will track it.     

Messages are always stitched if

  •           They are the same message
  •           They are from the same luw (disluw prevents that)
  •           They have the same correlator