| Overview | Package | Class | Deprecated |
The 5620 SAM-O JMS interface has evolved over several releases. This page identifies changes to the JMS interface. Changes are divided into two sections, event changes and interface changes. They are listed at a high level, detail of the change is defined in the developers guide. Please review the JmsTest class for examples on how to handle backwards compatibility for changes identified below.
Release SAM 5.0 R10 to SAM 6.0
- ALA_span appears in the message header indicate object span of control.
- ALA_OLC appears in the message header to indicate object life cycle state. The value is 0 when the object has no OLC state and is set to 1 or 2 when the object has an OLC state.
- ALA_isCorr appears in the message header of ObjectCreation and AVC alarm events to indicate correlated alarms. Alarms may be correlated after they are created.
- OLCUpdateCompletedEventXMLFormat - This event is generated when OLC state changes for an object.
- All events specific to the 5650 Control Plane Assurance Manager (CPAM) have a ALA_category of CPAM
- StateChangeEvent - jmsStartTime appears in the SystemInfoEvent message body to indicate the last JMS server start time.
- Jar changes - SAM-O jars (samOssJBoss.jar, samOss.jar or samOssNoJms.jar) contain a manifest to identify the SAM release. SAM-O client applications must use the jar that corresponds to the same SAM release.
- Multiple releases: If the OSS client must connect to multiple versions of the 5620 SAM, the OSS must run a separate JVM with the samOss.jar that corresponds with each version of the 5620 SAM. 5620 SAM version information is included in the jar manifest file. Alternatively, the OSS client can use multiple class loader instances in the same JVM to access multiple versions of the samOss.jar
- Session expiry and reconnections: If a JMS client experiences an ungraceful shutdown, the client may experience reconnection exceptions(javax.jms.IllegalStateException) until the JMS server session expires.
- Message limits: Durable clients are not disconnected when message limits are exceeded. Messages for the client are dropped and a StateChangeEvent event is subsequently sent with a state value of JmsMissedEvents to notify durable subscribers of the deleted messages.
- There is a limit of 1000 JMS messages in memory for non-durable subscribers. Messages will be dropped if this limit is exceeded.
- The maximum value of 100 000 JMS messages applies to each durable subscription.