Friday, February 25, 2011

How to setup Java remote debugging in Eclipse

How to remote debug Java application in Eclipse IDE
Remote debugging is not a new concept and many of you are aware of this just for who don’t know what is remote debugging? It’s a way of debugging any process could be Java or C++ running on some other location from your development machine.  Since debugging Java application is essential part of Java development and ability to debug your application not only saves time but also increase productivity. Local debugging is the best way to debug Java program in my opinion and should always be preferred over remote debugging as discussed in my post How to debug Java program in Eclipse, but if local debugging is not possible and there is no way to debug your process then remote debugging Java application is the solution.  All Major IDE like NetBeans, Eclipse, IntelliJ allows you to remote debug Java program but I mostly use Eclipse for remote debugging Java application because it's free and standard IDE in Investment banks for Java projects. By the this is second article on Eclipse IDE in Javarevisited after sharing Top 30 Eclipse keyboard shortcuts to improve productivity in previous post.

Wednesday, February 23, 2011

Overriding equals() and hashCode() method in Java and Hibernate - Example, Tips and Best Practices

Override equals and hashCode in Java
Equals and hashCode in Java are two fundamental method which is declared in Object class and part or core Java library. equals() method is used to compare Objects for equality while hashCode is used to generate an integer code corresponding to that object. equals and hashCode has used extensively in Java core library like they are used while inserting and retrieving Object in HashMap, see how HashMap works in Java for full story, equals method is also used to avoid duplicates on HashSet and other Set implementation and every other place where you need to compare Objects. Default implementation of equals() class provided by java.lang.Object compares memory location and only return true if two reference variable are pointing to same memory location i.e. essentially they are same object. Java recommends to override equals and hashCode method if equality is going to be define by logical way or via some business logic and many classes in Java standard library does override it e.g. String overrides equals,  whose implementation of equals() method return true if content of two String objects are exactly same. Integer wrapper class overrides equals to perform numerical comparison etc.

Tuesday, February 22, 2011

How to execute native shell commands from Java Program

How to execute native shell commands from JAVA
Though it’s not recommended but some time it’s become necessary to execute native operating system or shell command from JAVA, especially if you are doing some kind of reporting or monitoring stuff and required information can easily be found using native command. This is not advised though because then you will lose platform independence which is why we mostly used JAVA.

Anyway if you no choice and you want to execute native commands from JAVA then its good to know that how we can do it, many of you probably know this but for those who don't know and have never done it we will see through an example.

Friday, February 18, 2011

FIX Protocol tutorials: Difference between Session Level Reject and Business message Reject

FIX Protocol tutorials: Difference between Session Level Reject and Business message Reject
In FIX protocol there are multiple ways of rejecting message some of them are using an Execution Report (MsgType=8) and ExecType=8 to reject a FIX message if it can not be acceptable by exchange e.g. Sending order for an exchange and link between broker and exchange is down. Another way of rejecting message is OrderCancelReject (FIX MsgType=9) which is used to reject amend (OrderCancelReplace message FIX MsgType 35=G) and cancel (OrderCancelRequest FIX MsgType=F) messages if its not possible to modify or cancel original message e.g. Sending Cancel request to an already filled order will be rejected by OrderCancelReject message in FIX protocol.

Thursday, February 17, 2011

Repeating groups in FIX Protocol

FIX Protocol repeating group
In this FIX protocol tutorial I am going to share my experience about FIX repeating block or group. This is fundamental concept of FIX protocol and used to carry repeating data. Correct understanding of various available FIX repeating groups e.g. PartyID block, Allocation repeating group etc is very important for writing FIX based software. In this FIX tutorial I will explain about how to parse a repeating group, how to prepare a repeating group and how to understand a repeating group. If you like to know more about basic concepts in FIX protocol then you may find my FIX Protocol tutorial interesting.

Monday, February 14, 2011

TIBCO Ledger file in Certified messaging : TIBCO Tutorial

TIBCO Ledger files in certified messaging
This is in continuation to my previous article on TIBCO Certified messaging, in this TIBCO tutorial we will discuss about what is TIBCO ledger? What is process based ledger and what is file based ledger?  Which messages are stored in TIBCO ledger? What are advantage and disadvantage of using TIBCO ledger? When should we use Process based and File based ledger etc. if you would like to read my earlier TIBCO Tutorial please see.

Saturday, February 12, 2011

How to implement Thread in Java ?Example of Runnable interface

How to implement Thread in Java
In my opinion Thread is the most wonderful feature of Java programming language and I remember when I started learning Java in one of programming class in India how important Thread was portrait and how much emphasis given on clear understanding of multi threading. It’s indeed still popular and one of most sought after skill in Java because writing concurrent and multi-threaded application in Java is challenging, despite Java providing excellent support at language level using synchronized and volatile keyword. Main problem with using multiple threads and writing multi-threaded code is issues related to concurrency e.g. deadlock, livelock,  race conditions etc, It takes lot of effort to implement multi-threading correctly in Java application.  In this core java tutorial I will share my experience on different way of implementing Thread in Java; Difference between Thread and Runnable in Java is also a very common core java interview question and asked mostly during junior level java interview.

Saturday, February 5, 2011

FIX Protocol Session or Admin messages tutorial

FIX Protocol Session or Admin messages tutorial

I have been working in FIX protocol for almost 5 years when I started working on FIX protocol I looked upon internet for some good tutorial which could supplement or complement lengthy FIX protocol specification there was nothing at that time so when I started my blog I thought to write about my own experience in FIX protocol as short, clear and concise tutorial format. Since I like question answer type of knowledge sharing too I have written some blog post on FIX protocol Interview questions you may find it interesting.

In today’s FIX tutorial we are going to have a look on FIX protocol session level messages. As you guys may know all FIX messages can be broadly classified in two categories Admin messages also called session level messages and Application messages which include Trade, pre trade and post trades messages.  Understanding of how FIX session works is very important because until you know the fundamental of FIX Sequence number, how does FIX session gets connected , what are the sequence of messages that flows between Sender Fix Engine and receiver FIX engine you won’t be able to quickly identify any problem related to FIX protocol.  FIX specification is very clear about what should FIX engine do on various FIX session connection / disconnection scenario.

Just to revise as per FIX protocol first Sender FIX Engine and receiver FIX engine connects to each other on TCP/IP protocol on specified IP and Port via leased line , Radianz link , Virtual Private network(VPN) or via internet. Once TCP Socket level connectivity established Sender application sends Logon (fix tag 35=A MsgType=A) with agreed SenderCompID (fix tag 49) and TargetCompID (fix tag 56). Receiver FIX engine receives this message and authenticate Sender FIX Engine client based upon SenderCompID (fix tag 49) and TargetCompID (fix tag 56) ,if client is authenticated successfully then receiver fix engine replies with same sends Logon (fix tag 35=A) message and connection is successfully established and then both FIX engine will send Heartbeat messages (fix tag 35=0) at specified  heartbeat interval to keep connection alive. In case receiver FIX engine is not able to authenticate client it will send a Logout message (fix tag 35=5) and connection will be terminated though socket connection will still be there. Receiver FIX engine can also send Logout message (fix tag 35=5) if it receives fix message with sequence number lower than it is expecting.

Now let’s see each of session level or Admin messages in little detail. You can always refer FIX protocol specification document and that is recommended also to get complete description of each of these messages.
Some important Session level or Administrative messages specified in FIX specification are following:
Heartbeat messages are denoted by MsgType=0 in financial information exchange (FIX) Protocol. Both FIX Session Initiator and FIX Session Acceptor sends each other Heartbeat messages to keep FIX session alive on a interval defined by Heartbeat Interval which is usually 30 or 60 seconds. If you see Heartbeat message (FIX tag 35=0) in your FIX Engine log file means your FIX session is up and connected.

Logon message is denoted by FIX tag 35=A and it is used to send login message from FIX initiator. As per FIX Protocol once TCP connection between FIX Initiator and FIX Acceptor got established, FIX initiator sends Logon message (tag 35=A) with pre agreed SenderCompID (tag 49) and TargetCompID (tag 56) and with Sequence No (FIX tag 34) expecting by FIX Acceptor. When FIX Acceptor receives Logon request (MsgType=A) it authenticate FIX session based on CompID specified in FIX Message and Sequence No and reply back with either Logout (tag 35=5) message or Logon(tag 35=A)  message based upon result of authentication.

Resend Request
Resend Request (FIX tag 35=2 or MsgType=2) is used for asking of retransmission or replay of lost messages during transmission or due to incorrect sequence number. It’s normally sent by the FIX Engine which is receiving message to initiate the retransmission of messages. FIX Engine uses Resend Request (tag 35=2) if a sequence number gap is detected or if FIX Engine of receiving application lost a message or as a part of initialization process to make sequence number in sync.
Resend Request (FIX tag 35=2 or MsgType=2) can be used to request a single FIX message, a range of FIX messages or all FIX messages subsequent to a particular FIX message.
Its worth noting that sending FIX Engine may like to consider the message type when resending messages; e.g. if a new order is in the resend series and a significant time period has been passed since it was originally sent, the sender FIX Engine may not wish to retransmit the order since market dynamics an price etc might have been changed also this may result in stale order reject which is done by Order Management Systems (OMS). (The Sequence Reset (FIX tag 35=4 or MsgType=4) Also called as Gap Fill is used to skip FIX messages that a sender FIX Engine does not want to resend.)

It is mandatory that the receiving FIX Engine process messages in sequential order, e.g. if FIX message number 11 is missed and 12-13 received, the application should ignore 12 and 13 and ask for a resend of 11-13, or 11 -0 (0 denotes infinity). Second approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides of FIX Engines are simultaneously attempting to recover a sequence number gap.

Test Request
In financial information exchange also called FIX Protocol Test Request is denoted by FIX tag 35=1 or MsgType=1. Test Request FIX Message is used by FIX Engine to forces a heartbeat from the opposing FIX Engine. The Test Request (FIX tag 35=1) message checks sequence numbers or verifies communication line status. The opposite FIX Engine responds to the Test Request Test Request (FIX tag 35=1) with a Heartbeat (FIX tag 35=0) containing the TestReqID (FIX tag 112).
The TestReqID FIX tag 112) verifies that the counterparty FIX Engine is generating the Heartbeat (FIX tag 35=0) as the result of Test Request (FIX tag 35=1) and not a normal timeout. The opposite FIX Engine includes the TestReqID (FIX tag 112) in the resulting Heartbeat (FIX tag 35=0). Any string can be used as the Heartbeat (FIX tag 35=0) (Some fix engine generally uses a timestamp string).

Session Level Reject
In financial information exchange (FIX) protocol Session level Reject or  Reject  message is denoted by FIX tag 35=3 or MsgType=3.  Session level Reject is used by FIX engine when a fix message is received but cannot be properly processed due to a session-level rule violation as specified in FIX Protocol specification document. As an example FIX Engine will use Session level Reject or a reject it receives a FIX message with invalid basic data (e.g. MsgType 35 =$) which successfully passes de-encryption, Checksum (FIX tag 10) and BodyLength (FIX tag 9) checks. As a rule FIX messages should be forwarded to the trading application for business level rejections whenever possible.
Rejected messages should be logged into log file and the incoming sequence number must be incremented by FIX Engine.

Its worth noting that receiving FIX Engine  should disregard any FIX message which  is incorrect , cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence number mismatch and a Resend Request (FIX tag 35=2 or MsgType=2) will be generated and passed to counter-party FIX Engine.
Generation and receipt of a Reject (FIX tag 3) message indicates a serious error that may be the result of faulty logic in either the sending or receiving FIX Engine.
If the sending FIX Engine chooses to retransmit the rejected message, it should be assigned a new sequence number (FIX tag 34) and sent with PossResend (FIX tag 97) =Y.
Its recommended  to describe the cause of reject in the fix tag  Text (FIX Tag 58)  which then can be used by receiving FIX engine or developer to identify actual cause of Session level reject  (e.g. Price tag is missing in Limit Order).

Below are some scenarios where session-level Reject (FIX Tag 3 or MsgType=3) can be used.
CompID problem: Either FIX Initiator or FIX Acceptor is sending incorrect SenderCompID (tag 49) and TargetCompID (tag 56).
Invalid MsgType: Either FIX initiator or FIX Acceptor is sending MsgType other than specified in FIX Specification for that particular FIX Version e.g. FIX4.2
Incorrect data format for value: If a FIX tag has a data type Timestamp and FIX engine is sending some other data type
Required tag missing: Either FIX Initiator or FIX Acceptor is not sending mandatory FIX tag in a particular FIX message e.g. Price (FIX tag 44) missing in a NewOrderSingle (MsgType=D) message with OrdType =2 i.e. Limit Order.
Invalid tag number: Either FIX initiator or FIX Acceptor is sending any tag other than specified in FIX Specification for that particular FIX Version e.g. FIX4.2
Tag not defined for this message type: Either FIX initiator or FIX Acceptor is sending any tag other than specified in FIX Specification for that particular message type e.g. Sending TestReqID in logout message.
Undefined Tag: In case any of sender FIX engine is sending custom tag and that is not configured or supported by Revenging fix engine.
Tag specified without a value: e.g. 35= and there is no value for that particular fix tag. Its not a valid fix message and so receiving fix engine will reject it.

Sequence Reset
Sequence Reset also called as Gap fill messages is denoted by FIX tag 35=4 or FIX MsgType 35=4. It is used in response to Resend Request (FIX tag 35=2 or MsgType=2) by sending FIX engine to reset the incoming sequence number on the opposing side FIX engine. Sequence Reset message (fix tag 35=4) operates in two different modes one in which GapFillFlag (FIX tag 123) is 'Y' also called Sequence Reset - Gap Fill and second mode on which GapFillFlag (FIX tag 123) is 'N' or not present also called Sequence Reset - Reset mode. As per FIX protocol specification the "Sequence Reset (fix tag 35=4)-Reset" mode should ONLY be used to recover from a disaster situation which cannot be otherwise recovered by "Gap Fill" mode.

The Sequence Reset or GapFill message (fix tag 35=4) can be useful in the following circumstances:
1. While processing Resend Request (FIX tag 35=2 or MsgType=2) sending FIX Engine may choose not to send a message (e.g. a stale order). The Sequence Reset (fix tag 35=4) - Gap Fill can be used to fill the place of that message.
2. While processing Resend Request (FIX tag 35=2 or MsgType=2) sending FIX Engine may choose not to send a message if all the messages are only administrative or session level messages, because there is no point on resending them in that case also Sequence Reset (fix tag 35=4) - Gap Fill is used to fill the message or sequence gap.
Logout message is denoted by FIX tag 35=5 or MsgType=5 in FIX protocol specification and it is used to terminate or close any FIX session. In case receiver FIX engine is not able to authenticate client it will send a Logout message (fix tag 35=5) and connection will be terminated though socket connection will still be there. Receiver FIX engine can also send Logout message (fix tag 35=5) if it receives fix message with sequence number lower than it is expecting. The Logout message (fix tag 35=5) is used to terminate a FIX session. Termination or disconnection without the exchange of Logout message (fix tag 35=5) messages is treated an abnormal condition.
Exchange of Logout message (fix tag 35=5) before actually terminating or closing the session allows the initiator FIX engine to perform any kind of Sequence Reset (fix tag 35=4) or Gap fill operations that may be required or necessary. Logout initiator should also wait for the opposite FIX engine to respond with a confirming Logout message (fix tag 35=5) it can terminate the session in case the remote FIX Engine does not respond within a specified time period.

To read more about FINANCIAL INFORMATION EXCHANGE (FIX) protocol, see my FIX Protocol tutorial series. 

Related post:

FIX Protocol Tutorial 2: Basics of FIX Protocol and FIX Engine

Friday, February 4, 2011

Introduction to Tibco Hawk as Tibco Tutorial

Tibco Hawk
This is another short  TIBCO tutorial from my TIBCO tutorial series. in this i am gonna discuss what is TIBCO hawk , Where do we use TIBCO hawk , What are components of TIBCO hawk , what benefit TIBCO hawk offers and how Tibco hawk works.  if you are interested to know more about TIBCO  Rendezvous , TIBCO EMS and there fundamental concept  or if you are looking for some TIBCO Interview questions you may find this link interesting TIBCO Tutorial

Wednesday, February 2, 2011

How HashMap works in Java

How HashMap works in Java or sometime how get method work in HashMap is a very common question on Java interviews now days. Almost everybody who worked in Java knows about HashMap, where to use HashMap and difference between Hashtable and HashMap then why this interview question becomes so special? Because of the depth it offers. It has become very popular Java interview question in almost any senior or mid-senior level Java interviews. Investment banks mostly prefer to ask this question and some time even ask you to implement your own HashMap based upon your coding aptitude. Introduction of ConcurrentHashMap and other concurrent collections has also made this questions as starting point to delve into more advanced feature. let's start the journey.