Skip Navigation Links | |
Exit Print View | |
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Part I Introduction to Message Queue Administration
1. Administrative Tasks and Tools
3. Starting Brokers and Clients
6. Configuring and Managing Connection Services
8. Configuring Persistence Services
9. Configuring and Managing Security Services
10. Configuring and Managing Broker Clusters
11. Managing Administered Objects
12. Configuring and Managing Bridge Services
13. Monitoring Broker Operations
14. Analyzing and Tuning a Message Service
17. Broker Properties Reference
18. Physical Destination Property Reference
19. Administered Object Attribute Reference
20. JMS Resource Adapter Property Reference
21. Metrics Information Reference
22. JES Monitoring Framework Reference
A. Distribution-Specific Locations of Message Queue Data
B. Stability of Message Queue Interfaces
HTTP/HTTPS Support Architecture
Step 1 (HTTPS Only): Generating a Self-Signed Certificate for the Tunnel Servlet
Step 2 (HTTPS Only): Specifying the Key Store Location and Password
To Specify the Location and Password of the Certificate Key Store
Step 3 (HTTPS Only): Validating and Installing the Server's Self-Signed Certificate
To Validate and Install the Server's Self-Signed Certificate
Step 4 (HTTP and HTTPS): Deploying the Tunnel Servlet
To Deploy the HTTP or HTTPS Tunnel Servlet
Modifying the Application Server's Security Policy File
Step 5 (HTTP and HTTPS): Configuring the Connection Service
To Activate the httpjms or httpsjms Connection Service
Step 6 (HTTP and HTTPS): Configuring a Connection
Installing a Root Certificate (HTTPS Only)
Configuring the Connection Factory (HTTP and HTTPS)
Using a Single Servlet to Access Multiple Brokers (HTTP and HTTPS)
This section describes possible problems with an HTTP or HTTPS connection and provides guidance on how to handle them.
The consequences of a server or broker failure in an (HTTP or HTTPS) connection vary depending on the specific component that has failed:
If the application server or Web server fails and is restarted, all existing connections are restored with no effect on clients.
If the broker fails and is restarted, an exception is thrown and clients must reestablish their connections.
In the unlikely event that both the broker and the application server or Web server fail and the broker is not restarted, the application server or Web server will restore client connections and continue waiting for a broker connection without notifying clients. To avoid this situation, always restart the broker after a failure.
If an HTTPS client cannot connect to the broker through the tunnel servlet, do the following: