The initial tab shows server general information including JVM overview, thread pool activity and logs.

• JVM, shows the Java virtual machine version, PID (linux process id), memory and CPU & JVM load.

• Thread Pool, is the core implementation of a thread pool used to serve http connection requests. The initial parameters like core pool size and maximum pool size, and the current pool size measures the number of threads available for http request.

  Indicator	Description
  Core pool size	The core number of threads.
  Max pool size	The maximum allowed number of threads.
  Current pool size	The current number of threads in the pool.
  Completed task count	The approximate total number of tasks that have completed execution.
  Rejected count	The number of tasks rejected cause pool was full.
  Error count	The number of tasks rejected by task error
  Completed / second	The number of tasks completed per second
  Rejected / second	The number of tasks rejected per second
  Errors / second	The number of task errors per second
  Queue size	The number of threads in queue
  Active count	The approximate number of threads that are actively executing tasks
  Running	The approximate number of threads tasks including queued.
  Avg service time	$$\frac{getTotalServiceTime}{getNumberOfRequestsRetired}$$
  Avg response time	$$getAverageServiceTime + getAverageTimeWaitingInPool$$
  Avg time waiting pool	$$\frac{getTotalPoolTime}{getNumberOfRequestsRetired}$$
  Ratio Dead/Response Time	$$\frac{getTotalPoolTime}{getTotalServiceTime}$$
  Ratio QueueLength / Cores	In this method the getRequestPerSecondRetirementRate rate (RPSRR), or the observed rate at which requests are leaving the system is multiplied by the average time it takes to service a request yielding the average number of requests in the system. The result is divided by the number of cores. $$ RPSRR \times \frac{getAverageServiceTime + getAverageTimeWaitingInPool}{availableProcessors} $$
  Request/s Retirement Rate	$$\frac{getNumberOfRequestsRetired}{getAggregateInterRequestArrivalTime}$$

  An important advantage of the fixed thread pool is that applications using it degrade gracefully. If the application simply creates a new thread for every new HTTP request, and the system receives more requests than it can handle immediately, the application will suddenly stop responding to all requests when the overhead of all those threads exceed the capacity of the system. With a limit on the number of the threads that can be created, the application will not be servicing HTTP requests as quickly as they come in, but it will be servicing them as quickly as the system can sustain.

  Threadpool performance can be monitored using built in instrumentation. The parameters shown in the following table can be viewed under Threadpool panel.

• System monitor shows a timseries graphical view of JVM memory and CPU usage.
• Logs view shows the last logs reported by server logger.

The logs tab shows most recently logs generated by server. Even logs may be sent to disk or not they can be always viewed from console as they are keep in memory in a short list for at least 1000 items.

Logs have different sources indicating the application module AUTH, JAVA, HTTP, JDBC, POOL, etc. Java standard log levels are shown in a specific color.

• SEVERE
• WARNING
• INFO
• CONFIG
• FINE
• FINER
• FINEST

When a log has detailed information it can be viewed by clicking on it. For example, an Exception log may show the stack trace in the detailed view.

Debug level can be tuned for each logger in config.xml log section. The available loggers are:

• AUTH, logs authentication steps including failures using WARNING level.
• JAVA, logs Java related operations related to caches, virtual machine, etc.
• POOL, logs object pool related operations.
• JDBC, logs JDBC related operations.
• HTTP, logs HTTP related operations.
• SOAP, logs SOAP related operations.
• REST, logs REST related operations.
• OLAP, logs OLAP related operations.
• FOP, logs Apache FOP processor operations.
• FTL, logs Apache FreeMarker processor operations.
• XSL, logs XSL processor operations.
• XML, logs XML transform operations.
• TCP, logs TCP operations.
• SWT, logs SWT (Standard Widgets Tookkit) operations.

<debugLog>
         <enabled>false</enabled>
         <numFiles>16</numFiles>
         <directory>logs</directory>
         <default>CONFIG</default>
         <levels>
            <entry>
               <key>AUTH</key>
               <value>WARNING</value>
            </entry>
            <entry>
               <key>JAVA</key>
               <value>CONFIG</value>
            </entry>
            <entry>
               <key>POOL</key>
               <value>CONFIG</value>
            </entry>
            <entry>
               <key>JDBC</key>
               <value>CONFIG</value>
            </entry>
            <entry>
               <key>HTTP</key>
               <value>CONFIG</value>
            </entry>
            <entry>
               <key>SOAP</key>
               <value>CONFIG</value>
            </entry>
         </levels>
      </debugLog>

The object pool pattern is a software creational design pattern that uses a set of initialized objects kept ready to use – a pool – rather than allocating and destroying them on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished, it returns the object to the pool rather than destroying it; this can be done manually or automatically.

Object pools are primarily used for performance: in some circumstances, object pools significantly improve performance. Object pools complicate object lifetime, as objects obtained from and returned to a pool are not actually created or destroyed at this time, and thus require care in implementation.

Axional Server provides a fast object pool implementation that is mainly used to implement JDBC pooling. Using the pools tab, we can inspect internal pool structure, performance metrics and objects allocated and it's location in either the free or used queue.

Click on a pool to get a detailed pool view.

The JDBC tab shows information about JDBC connection pools agregated by node, server, database and pool. Each information level agreggates to it's parent from bottom to top.

JDBC pool is built on a hierarchical structure include a node, servers, database and pools.

The node refers to all server JDBC connections of any kind. The node view shows aggregated information for all JDBC views. This means you can see the aggregated metrics of all database servers and it's connections pools.

Shows aggregated information by JDBC server

Shows aggregated information by JDBC database

Shows aggregated information by JDBC pool on all active pools on JDBC node

Shows information of any JDBC active connection

Shows information of any JDBC active statement

Shows last SQL statements on any JDBC source

Shows top used SQL statements on any JDBC source

Shows top time consuming SQL statements on any JDBC source

Shows last SQL errors on any JDBC source

Shows information about registered JDBC drivers

Shows information about JDBC activity by server allowing a hierarchical view of all sub components.

Shows information about JDBC activity by database allowing a hierarchical view of all sub components.

Shows information about JDBC activity by pool allowing a hierarchical view of all sub components.

The connections tab shows active pool connections.

The statements tab shows active pool statements on all active connections.

Shows the statement history (including all connections since pool startup).

Shows top SQL operations by use count (including all connections since pool startup).

Shows top SQL operations by time consumed (including all connections since pool startup).

Shows the most accessed tables (including all connections since pool startup).

Shows the last errors (including all connections since pool startup).

Shows the elements in pool cache including table, access count, rows stored, storage type (ArrayList or MemoryMappedFile), and cached SQL.

Shows Blob metadata information loaded. This information is used to resolve blobs so they can be stored as references.

Shows the elements in pool cache including table, access count, rows stored, storage type (ArrayList or MemoryMappedFile), and cached SQL.

Axional Server uses different kind of cache structures to store long living data structures. They are intended to speed up applications by providing a means to manage cached data of various dynamic natures. Like any caching system, Axional Server Cache is most useful for high read, low put applications. Latency times drop sharply and bottlenecks move away from the database in an effectively cached system.

The foundation of Axional Server Cache is the VMTable Cache structure, which is the pluggable controller for a cache type. Four types of caches can be plugged into the VMTable Cache: (1) Maps, (2) Queues, (3) Futures, and (4) Sets.

Caches may belong to several server components types like:

JVM JDBC DISK PROC POOL SOAP MQTT MEMORY THREADS VTABLE JETTY STUDIO

Maps are caches with key-value pairs that can have a limit or not. There are several classes of caches bases on maps including LRUHashMap, ConcurrentHashMap, etc.

An LRU is a Map implementation with a fixed maximum size which removes the least recently used entry if an entry is added when full. The least recently used algorithm works on the get and put operations only. Iteration of any kind, including setting the value by iteration, does not change the order. Queries such as containsKey and containsValue or access via views also do not change the order.

Each cache shows it's detailed live information.

When an cache is selected, its contents can be explored in the detail view. The information varies depending cache content type.

A queue is a collection (sized or not) designed for holding elements prior to processing. Server supports several types of queues including:

• BlockingQueue
• ConcurrentLimitedQueue
• ConcurrentLimitedDequeue
• FixesSizePriorityQueue
• LinkedBlockingDeque

Examples of queues used in server structures are:

• BlockingQueuePool - witch holds used objects in object pool
• SQLStatementHistoryQueue - witch holds a list with last executed SQL statements
• SQLErrorQueue - witch holds a list with last SQL errors

When an cache is selected, its contents can be explored in the detail view. The information varies depending cache content type.

A Future is a data structure used to retrieve the result of some concurrent operation. This result can be accessed synchronously (blocking) or asynchronously (non-blocking).

Future caches hold Future objects. For example, most objects that may be created using a JDBC connection are stored in future caches like JDBCDatabaseMetaData (wrapper of java.sql.DatabaseMetaData).

When an cache is selected, it's contents can be explored in the detail view. The information varies depending cache content type.

Caches based on sets uses a NavigableSet implementation based on a TreeMap. The elements are ordered using their natural ordering, or by a Comparator provided at set creation time, depending on which constructor is used.

When an cache is selected, its contents can be explored in the detail view. The information varies depending cache content type.

Axional Server includes integrated support for REST applications based on Jersey RESTful Web Services framework. This framework for developing RESTful Web Services in Java provides support for JAX-RS APIs and serves as a JAX-RS (JSR 311 & JSR 339) Reference Implementation.

The REST tab shows deployed applications including details and activity measurement for each endpoint.

Select any rest application tab to se its enpoints and activity.

The SOAP tab can show either a SOAP server or a SOAP client configuration. Under the SOAP server, each deployed service is shown with its activity measurement.

All SOAP services deployed on a server can be monitored from this tab. For each SOAP service method, server keep performance statistics including throughput and transfer size for either input and output.

When a server acts as client for remote SOAP services, the client tab shows clients activity.

Axional Server provides client implementations of MQTT and MQTT-SN messaging protocols aimed at new, existing, and emerging applications for the Internet of Things (IoT).

The MQTT (Message Queuing Telemetry Transport) tab shows MQTT registered client subscribers on Axional Serverand its activity.

MQTT tab shows registered MQTT clients on server, topics subscribed and the number of messages arrived. To setup a MQTT client you can use AxionalMqttSbuscriber class and override MqttCallback interface methods.

This tab groups template rendering or transformation operations performed by server including Apache FOP transforms, Apache Xalan XSLT processor, HTMLUnit processing and Apache Freemarker template rendering.

Processors (except FTL) may take long to execute and may heavy consume CPU and memory. For example, a long FO document may take seconds to be rendered as a PDF document. To protect server, all those processors are run using a queued executor.

Processors that are subjected to thread pool execution are:

The Activity section shows the executor queue status of each processor. This section includes:

The FOP tab shows information about FOP rendering processes executed.

When a row is selected, the FOP XML source is shown, and when double-clicked, the generated PDF will be shown. Additional tabs will show rendering events, warning or errors. And the Fonts tab will show font families and triplets allowing generating a PDF will all available fonts.

FOP processed elements

FOP events of selected process

FOP Font families

FOP Font triplets

Previous Next

The XSL tab shows information about XSL transformations processes executed. XSL transformations are used for example when building a document from a XML data source.

 

 

 

Previous Next

The HTML tab shows server side HTML rendered pages using the HTMLunit processor. This feature it's mainly used during PDF generation of WYSIWSG documents with SVG graphics. During the generation of the XML FO document, server side redering of HTML page is used to extract the SVG image.

You can also enter an URL to do direct web scraping.

HTML processor

HTML processor text

Previous Next

Graphviz (short for Graph Visualization Software) is a package of open-source tools initiated by AT&T Labs Research for drawing graphs specified in DOT language scripts. Graphviz consists of a graph description language named the DOT language. DOT is highly customizable and it allows you to control line colors, arrow shapes, node shapes, and many other layout features

To run the Graphviz C code from Java, Axional Servers includes a port to javascript using emscriptem. Emscripten is an LLVM-based project that compiles C and C++ into highly-optimizing JavaScript in asm.js format.

 

 

Previous Next

The FTL tab shows information about FreeMarker template manager instances active.

Each server may setup a series of tasks for periodical execution. The Executors console tab show all server active tasks. Executors are divided in three categories according to its nature.

• EXECUTOR, that performs pooled execution with a limited queue.
• SCHEDULER, that performs periodic task execution at given intervals.
• CRON, that performs unix cron style task executions.

Some common Axional Server executors are:

• MemoryWarning [pool name], listens for memory warning recovery conditions.
• BloquingQueuePool[Cleanners], cleans pooled objects that are idle for so long.
• BloquingQueuePool[Passivate], runs a non-blocking passivate process when an object is returned to pool.
• JDBCTimeoutGuard[database], looks for long living querys that exceed a configuration timeout and fires the SQL cancel if need.
• FileCleaningTracker, perform the FileReference queue poll of PhantomReferences to fire cleaning of unused files.
• FOP, XSL & HTML processors, used to queue execution of document rendering.

And some specific of Axional Studio

• CrontabDaemon[user], holds a unix cron style executor for a given user.
• SQLBeanCacheRPCBroadcast, performs horizontal replication of cache changes.

Each executor shows detailed information about it's internal state, including fields like:

When a row is selected, detailed information about executor tasks is shown in the bottom window.

The JVM tab explores the Java VM instance

The main Java view shows information about JVM status

Memory console view shows information about heap and non heap memory pools (direct or mapped buffers). It also includes garbage collector statistics.

Server includes a Memory Warning Monitor (MWM) that listens for low memory conditions. It is automatically attached to HEAP memory pools with memory threashold supported.

During a low memory condition, server will:

1. Log a SEVERE message.
2. Perform a full GC.
3. Check if low memory condition persists after GC.
4. If persists, notify to all listeners (caches, pools, ...) that may remove data and perform a full GC again.
5. Set low memory condition state by checking condition.

If low memory condion is set, it will remain set until a MemoryWarning[Pool] executor checks memory has recovered a good condition. This way, during low memory condition, server may reduce activity to protect overloading.

By default, server enables memory warning monitor at 80% during startup unless changed by Java VM setting from command line flag
-Ddeister.axional.server.java.jvm.mem.JVMMemoryWarningMonitor=value.

Server startup code to setup MWM looks like:

int threshold = SystemUtils.getInitInt(JVMMemoryWarningMonitor.class, 80);
if (threshold > 0)
	JVMMemoryWarningMonitor.getInstance().setUsageThreshold(threshold / 100.0);

Axional Server uses off-heap memory to store long living objects. These objects are stored outside normal memory commonly referred as on-heap memory.

The on-heap store refers to objects that will be present in the Java heap (and also subject to GC). On the other hand, the off-heap store refers to (serialized) objects that are managed by Axional Server, but stored outside the heap (and also not subject to GC). As the off-heap store continues to be managed in memory, it is slightly slower than the on-heap store, but still faster than the disk store.

To solve the performance problem that arise when allocating thousands of little objects using off-heap memory, Axional Server implements a high performance off-heap memory manager. It is provided by MergingByteBufferPoolFactory class.

• MergingByteBufferPoolFactory, it's a factory to create off-heap memory pools using direct allocated ByteBuffer objects of a desired chunk size
• MergingByteBufferPool, it's each of the buffer pools (segments) managed by a pool factory. It can be used to allocated and free off-heap memory blocks without the overhead of direct allocation. Allocated blocks are re-linked with collindant blocks to reduce memory fragmentation
• MergingByteBufferPoolAlocator, shows the internal allocated blocks that mat be Free or Used. When used, its content is displayed.

Shows java VM thread information including state, CPU usage and estimated memory usage (on Sun JVM only).

Shows java stacktrace. You can also get a stacktrace from command line by doing:

$ jps

list of java pid running proceses

$ jstack [pid]

2016-10-30 12:49:44
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.65-b01 mixed mode):

"Attach Listener" #64 daemon prio=9 os_prio=31 tid=0x00007f814118f800 nid=0x9617 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-11" #63 daemon prio=5 os_prio=31 tid=0x00007f8140e60000 nid=0x6707 waiting on condition [0x00007000046be000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x000000072401cc30> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
....

Shows information about underlying hardware and operating system.

Shows java instance runtime properties

Gives information about underlying OS filesystems.

The temp folder used by server can be examined from this tab. The temp folder holds several directories, each on referring a server application component.

lsof is a command meaning "list open files", which is used in many Unix-like systems to report a list of all open files and the processes that opened them.

This tab shows the lsof (open files) related to current Java server process.

From Linux command line, you can explore Java VM open files by using:

$ lsof -p PID

COMMAND   PID USER   FD      TYPE             DEVICE  SIZE/OFF      NODE NAME
java    23416  axs  cwd       DIR                8,6      4096       175 /home/axs/studio
java    23416  axs  rtd       DIR                8,1      4096       128 /
java    23416  axs  txt       REG                8,6      7734  44998460 /home/jdk1.8.0_111/bin/java
java    23416  axs  mem       REG                8,6    207604 105587917 /home/jdk1.8.0_111/jre/lib/amd64/libdcpr.so
java    23416  axs  mem       REG                8,6    492629 105587880 /home/jdk1.8.0_111/jre/lib/amd64/libt2k.so
java    23416  axs  mem       REG                8,6      1024 131591013 /home/axs/studio/tmp/axional-23416/MemoryMappedListStore/[wic_admin@dbsrv1][informix:dpc][RW]/sql6604950430908628032.bin
java    23416  axs  mem       REG                8,6      1024 131585854 /home/axs/studio/tmp/axional-23416/MemoryMappedListStore/[wic_admin@dbsrv1][informix:dpc][RW]/sql2694546414501405258.bin
java    23416  axs  mem       REG                8,6    131072 131585844 /home/axs/studio/tmp/axional-23416/MemoryMappedListStore/[wic_admin@dbsrv1][informix:dpc][RW]/sql8701812905673063554.bin
java    23416  axs  mem       REG                8,6    525453 105587883 /home/jdk1.8.0_111/jre/lib/amd64/libfontmanager.so
java    23416  axs  mem       REG                8,6    413979 105587887 /home/jdk1.8.0_111/jre/lib/amd64/liblcms.so
java    23416  axs  mem       REG                8,6     37420 105587875 /home/jdk1.8.0_111/jre/lib/amd64/libawt_headless.so
java    23416  axs  mem       REG                8,6    772804 105587800 /home/jdk1.8.0_111/jre/lib/amd64/libawt.so
java    23416  axs  mem       REG                8,1    111080      1473 /usr/lib64/libresolv-2.17.so
java    23416  axs  mem       REG                8,1     27776      1455 /usr/lib64/libnss_dns-2.17.so
...

To explore tcp connections to server port 8080

$ lsof -iTCP@192.168.10.14:8080

COMMAND   PID   USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
haproxy   965 nobody    8u  IPv4 6319987      0t0  TCP web1:51636->web1:webcache (ESTABLISHED)
haproxy   965 nobody   15u  IPv4 6320103      0t0  TCP web1:51720->web1:webcache (ESTABLISHED)
haproxy   965 nobody   16u  IPv4 6316508      0t0  TCP web1:51088->web1:webcache (ESTABLISHED)
haproxy   965 nobody   19u  IPv4 6319614      0t0  TCP web1:51334->web1:webcache (ESTABLISHED)
haproxy   965 nobody   20u  IPv4 6318124      0t0  TCP web1:51224->web1:webcache (ESTABLISHED)
haproxy   965 nobody   22u  IPv4 6319186      0t0  TCP web1:50994->web1:webcache (ESTABLISHED)
haproxy   965 nobody   26u  IPv4 6319629      0t0  TCP web1:51342->web1:webcache (ESTABLISHED)
haproxy   965 nobody   27u  IPv4 6317741      0t0  TCP web1:50646->web1:webcache (ESTABLISHED)
haproxy   965 nobody   30u  IPv4 6316682      0t0  TCP web1:51696->web1:webcache (ESTABLISHED)
haproxy   965 nobody   33u  IPv4 6320145      0t0  TCP web1:51744->web1:webcache (ESTABLISHED)
haproxy   965 nobody   34u  IPv4 6319469      0t0  TCP web1:51182->web1:webcache (ESTABLISHED)
haproxy   965 nobody   38u  IPv4 6320056      0t0  TCP web1:51684->web1:webcache (ESTABLISHED)
haproxy   965 nobody   39u  IPv4 6319634      0t0  TCP web1:51346->web1:webcache (ESTABLISHED)
haproxy   965 nobody   41u  IPv4 6319658      0t0  TCP web1:51362->web1:webcache (ESTABLISHED)
haproxy   965 nobody   42u  IPv4 6316237      0t0  TCP web1:50322->web1:webcache (ESTABLISHED)   
...

A more detailed view of tcp connections to server port 8080

$ lsof -iTCP@192.168.10.14:8080 -n -P

COMMAND   PID   USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
haproxy   965 nobody    8u  IPv4 6319987      0t0  TCP 192.168.10.14:51636->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   15u  IPv4 6320103      0t0  TCP 192.168.10.14:51720->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   16u  IPv4 6316508      0t0  TCP 192.168.10.14:51088->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   19u  IPv4 6319614      0t0  TCP 192.168.10.14:51334->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   20u  IPv4 6318124      0t0  TCP 192.168.10.14:51224->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   22u  IPv4 6319186      0t0  TCP 192.168.10.14:50994->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   26u  IPv4 6319629      0t0  TCP 192.168.10.14:51342->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   27u  IPv4 6323420      0t0  TCP 192.168.10.14:52530->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   30u  IPv4 6316682      0t0  TCP 192.168.10.14:51696->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   33u  IPv4 6320145      0t0  TCP 192.168.10.14:51744->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   34u  IPv4 6319469      0t0  TCP 192.168.10.14:51182->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   38u  IPv4 6320056      0t0  TCP 192.168.10.14:51684->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   39u  IPv4 6319634      0t0  TCP 192.168.10.14:51346->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   41u  IPv4 6319658      0t0  TCP 192.168.10.14:51362->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   42u  IPv4 6321218      0t0  TCP 192.168.10.14:52218->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   47u  IPv4 6316614      0t0  TCP 192.168.10.14:51366->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   48u  IPv4 6320398      0t0  TCP 192.168.10.14:51912->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   49u  IPv4 6319900      0t0  TCP 192.168.10.14:51550->192.168.10.14:8080 (ESTABLISHED)
haproxy   965 nobody   52u  IPv4 6319742      0t0  TCP 192.168.10.14:51444->192.168.10.14:8080 (ESTABLISHED)    
...

You can add a tcp tunnel for diagnostics. The tunnel can be establish a listen port on local computer that will forward requests to an ip address and port. When established, all incoming traffic to the listen port will be dump in the client section. And all traffic coming as a response will be dump under the server section.

For example, to explore a SOAP request and response we can:

• Establish a tunnel to our server using the standard port + 1
• Perform the soap call to the tunnel port.
• Traffic across tunnel port is redirected to server port while data is captured and logged in tcp console.

// we do not accept gzip responses    
call.getSOAPContext().setAcceptGzip(false);
// do not send gzip message call
call.getSOAPContext().setSendGzip(false);

For Jetty server implementation, this tab show information about Jetty deployed contexts and resources.

The hierarchy tab shows a hierarchical view of server handlers.

Shows webapp contexts deployed.

Shows servlet contexts deployed.

Shows contexts deployed.

Shows resource handlers deployed.

Shows session managers deployed and for each session manager, the list of active sessions.

Shows websockets per servlet context.

Shows server I/O statistics.

The console gives access to the TPC style command line console. Type help to see the list of available commands.

Type any command to see the results in either text console or result table. For example, to see available REST endpoints type:

$ rest

And to see the details of and endpoint named apps type:

$ rest apps

To see active JDBC connections type:

$ jdbc connections