Panel
borderColor #0288D1 bgColor #F7F7F7 borderStyle solid
Column width 500px Table of Contents Column width 400px

Diagnostic Levels

Architecture

The plugin uses two queues to handle messages (IN, OUT). Each JIRA instance has these queues.

Please, read below all marks carefully. This is quite low level introduction which understanding may be crucial to resolve some problems.

• Message are stored in queues.
• Messages are flush after some period of time (see Services).
• There are several services and each service may have several tasks in sequence. For example OutgoingService do following:
  • Process outgoing messages in NEW status (message types: Create, Update, Comment)
  • Process outgoing messages in RETRY status (message types: Create, Update, Comment)
  • Process outgoing messages in RETRY status (message types: Attachment)
  • Process outgoing messages in NEW status (message types: Attachment)
• So you can image that single flush may not be able to process all data-synchronization at once. 
  • Each service can execute in different order each time (depending on cron and execution duration).
  • Each service has some tasks that change message statuses which need to wait for next service execution to process further.
  • Communication depends on execution from both JIRAs. Flushing local queues is not enough to make synchronization happen. They need to be flushed on remote JIRA too.
• You can make flush faster from Synchronization web panel on issue (described below).
• Messages (and services) have two main categories:
  • Data (fields, comments, attachments)
  • Confirmation / Response (only for acknowledge)
• Queues are in JIRA DB. You can browse them with right tool (SQLDeveloper, Heidi, MySQL Query Browser, etc.).
• Communication is made using HTTP protocol. You can sniff this communication with tools like HTTPNetworkSniffer.
• Changes on issues are in 90% made using JIRA REST API. However this API is called from local JIRA (not remote).
  So this is internal HTTP communication.
• There are different strategies to handle: create-update, comments, attachments. So HTTP messages may differ.
• Data format is JSON.

Preinstalled Components

During installation plugin create one custom field:

• InTENSO [Synchronizer] - Synchronized issues

There is another custom field that can be setup manually:

• InTENSO [Synchronizer] - Synchronized issues view 

Under the hood there are 7 services responsible for synchronization task:

• Outgoing Job -  it is responsible for sending changes data to remote JIRA,
• Incoming Job -  it is responsible for handling data receipt from remote JIRA,
  
• Outgoing Response Job - responsible for sending changes confirmation to JIRA which started data synchronization,
• Incoming Response Job - deals with incoming responses (mark data as synchronized),
• Archivization Job - move all synchronization data marked as done to archive,
• Pull Job - when JIRA is behind firewall(connection is in passive mode) and is not able to send synchronization data to remote instance, pull job in remote JIRA fetch data and performs synchronization,
• Pull Response Job - when JIRA is behind firewall(connection is in passive mode), this job in remote instance fetch all acknowledge information(it's similar to Outgoing Response Job, but works only when connection is in passive mode).

You can decide how often jobs run, to do that set whatever Cron expression you like in general configuration of the synchronizer.

See also Services

Synchronization Level

Synchronization
Issue Panel 

There is a web panel on issues that have a (2) Contract set.

Image Removed

Panel sections:

• General warning are shown on top (

  Status
  colour Yellow title warn

  ) and they should NOT be ignored. They may provide you quick answer why synchronization is not performed.

• Connections & Contracts
  • First line is a (1) Connection name and mode (

    Status
    colour Green title active

    or

    Status
    colour Yellow title Passive

    )
  • Below is a (2) Contract name and its status (

    Status
    colour Green title Enabled

    or

    Status
    colour Yellow title disabled

    )
    • Additional contract configuration is listed below.
      So for example if comments are not synchronized you may see that they are not enabled or you need to use External Comments Tab.
  • There can be many Connection/Contract for one issue.
• Message Types
  • Left group is for CREATE, UPDATE, ATTACHMENTS
    • Each message should receive RESPONSE (number of responses should match sum of messages)
    • Arrow next to CREATE informs whether issue was create in local JIRA (->) or remote (<-)
  • Right group is for COMMENTS
    • The flag icon informs that there is a message that waits for processing. You can see also that there is one response missing for comments.
• Outgoing & Incoming
  • 1/23 means that 23 outgoing messages were processed successfully. One is still processing.
  • It is not very likely you will see NEW & PROCESSING messages in Incoming queue because they are processed instantly. However, if you see messages there for a while that may indicate a problem.

Show Logs opens Log Browser in context of given issue (for more see Log Browser).

Image Removed Can be used to force queues processing. It is good for evaluation to speed-up a communication a bit. You can flush after making a changes that should be synchronized. Processing incoming changes and responses. You may need few seconds to see the change on the issue. After flush you should also refresh a page (F5).