The log message, Core-5688-696: received request for unknown source, now displays an IP and port number. Also, the new message, Core-7427-1: received TSNI request for unknown source - ip:port[%s:%d], differentiates between a request and a TSNI request from an unknown source.
The following new warning messages indicate when a UM receiver delivery controller reaches its maximum map entries, which could cause Late Join to end prematurely.
CoreApi-7506-1: rdelvc force loss due to dctlr_entries exceeding ctx_max_entries!
CoreApi-7506-2: rdelvc force loss when doing Late Join or OTR due to dctlr_entries exceeding ctx_max_entries!
The log message Core-5688-7 FATAL: failed assertion... has been removed. In addition to removing this message, a backtrace has been added to platforms with backtrace support.
UM now uses the multicast interface in the OTID to reduce the possibility of an OTID collision in sources. A collision of a source OTID can cause a receiver to join only one of the source streams as it sees the second as a duplicate.
The resolver_unicast_daemon option now issues the new log message, CoreApi-7875-1: optval cannot contain multiple values, to indicate that multiple values are not allowed for this option:
The lbmsdm.h file now contains a check to not typedef intx_t types for Windows platforms that have these already defined.
Corrected a problem that caused lbmrd to propagate non-LBMR messages to clients.
UM now allows for NAT translation of request/response and Late Join.
Corrected a problem that could cause indefinite EWOULDBLOCK on the Windows platform.
Corrected a problem where an active lbmrd erroneously logged message LOG Level 6: Core-5688-3375: unicast resolver xxx.xxx.xxx.xxx:xxxx went inactive
The .NET API does not support message selectors with unicode symbols and causes receiver creation to fail.
UM does not support the use of Unicode PCRE characters in wildcard receiver patterns on any system that communicates with a HP-UX or AIX system.
Hot Failover is not currently supported with Multitransport Threads.
Configuring sources with LBT-RU, source-side filtering, and adaptive batching may cause a crash. All three options must be set to cause the problem. Informatica is working to address this issue.
When using the UM Gateway Informatica recommends that you do not enable the Multitransport Threads feature. Informatica does not support nor test the operation of Multitransport Threads across the UM Gateway.
Multitransport Threads do not support persistent stores (UMP) or queues (UMQ).
When using Event Queues with the Java API on Mac OS X kernel 9.4, core dumps have occurred. Mac OS X kernel versions prior to 9.4 have not produced this behavior. Informatica is investigating this issue.
Sending LBT-IPC messages larger than 65,535 bytes is not supported when ordered_delivery has been set to 0 (zero) unless you set transport_lbtipc_behavior to receiver_paced.
When using the LBT-RDMA transport with Java applications, a segfault can occur if you kill a receiver with Ctrl-C. As a workaround, use the JVM option, -Xrs. Informatica is investigating this problem.
If you use the current version of VMS (3.2.8), UMS 4.1 issues the following warning: LOG Level 5: LBT-RDMA: VMS Logger Message (Error): vmss_create_store: 196[E] vms_listen: rdma_bind_addr failed (r=-1). This warning indicates that rdma_bind failed for ethernet interfaces, which is expected behavior. Currently, VMS attempts rdma_bind on all interfaces. When released, VMS version 3.2.9 will only run rdma_bind on infiniband-capable interfaces.
When using Automatic Monitoring with ud_acceleration and the epoll file descriptor option, UMS may leave a monitoring thread running after context deletion. Informatica is investigating this problem.
At the present time, 32-bit applications cannot interact with 64-bt applications using the LBT-IPC transport. As a result, a 64-bit UM Gateway cannot interact with a 32-bit application using LBT-IPC. It can only interact with a 64-bit application. Likewise, a 32-bit UM Gateway can only interact with a 32-bit application.
The UM Gateway does not currently support gateway failover, MIM, persistence, queuing, JMS, or Ultra Load Balancing. Gateway support of these features is in development.
The UM Gateway is not supported as a standalone Windows service at this time. This will be resolved in a future release.
The UM Gateway does not currently support a four gateway "full-mesh" configuration (i.e., all gateways connected).
If using LBT-RDMA across the UM Gateway and you exit the gateway with Ctrl-C, you may see a segfault. Informatica is aware of this and has not observed any ill effects from this segfault.
Informatica recommends against configuring UM Gateways in a ring of peer portals - use configurations utilizing gateway endpoints (parallel paths) to break the ring.
Informatica recommends not stopping and restarting UM Gateways within the transport's activity timeout period (transport_*_activity_timeout defaults to 60 seconds for LBTRU and LBTRM).
If proxy sources are enabled and gateways bounce, you may see a fatal assertion.
Although UMS 5.0 applications should run well with LBM 4.2 UM Gateways, all Gateways should always run the same version.
Port=0 is no longer a valid port number for umestored (UMP or UMQ). Log Messages Store-5688-5408 and Store-5688-5410 now indicate that port 0 is no longer valid. The valid port range in the messages is now [1,65535].
A webmon port in the umestored configuration file now must be greater than 0. Specifying a port of 0 or anything that would be translated to a value less than 0 prohibits umestored from starting and instead you see web-monitor port must be greater than 0.
Fragments requested for retransmission by a receiver from a store may now be declared as unrecoverable prior to the retransmission request timeout, if all stores have declared that fragment unrecoverable.
Log messages Store-5688-5332 and Store-5688-5333 are added to the Operations Guide.
No problems specific to UMP were addressed.
Creating multiple receivers on the same topic in the same context using the Java API may result in a crash when
calling Dispose() if the topic is a persistent data stream.
It is recommended to either protect the calls to Dispose()
to prevent concurrent calls or use a single receiver per topic and use application code
to deliver messages to different callbacks. This will be fixed in a future release.
UMP stores sometimes fail to send message stability acknowledgements to sources for messages sent while the store was being reported unresponsive by the source. Informatica is investigating this problem.
A UMP store daemon, umestored, may crash if you enable proxy sources and the daemon is configured with a very restrictive port range, ( transport_lbtrm_multicast_address_low - transport_lbtrm_multicast_address_high, transport_tcp_port_low - transport_tcp_port_high, etc.). Informatica recommends that you use a wide port range (at least 1000 ports) in your UM configuration file if you enable proxy sources for umestored. Informatica is investigating this problem.
The UMP store daemon, umestored, stops persisting messages to disk if the store has a loss condition which is not resolved prior to an EOS event. As a workaround, Informatica recommends that you enable receiver delivery_control_loss_check_interval 2500 in the UM configuration file, not the umestored XML configuration file. The value of 2500 assumes the default *_nak_generation_interval. See Preventing Undetected Loss for more information. Informatica is investigating this problem.
Receivers using event queues and Spectrum with UMP can experience a SIGSEGV while shutting down if events still exist on the event queue when it is deleted. As a workaround, use LBM_EVQ_BLOCK when dispatching event queues. During application shutdown, call lbm_evq_unblock() after deleting receivers associated with the event queue, but before deleting any context objects. Once the dispatch thread exits, it is safe to proceed with context deletion. Informatica is working on a solution to this problem.
When running a store on a Solaris machine, you may experience registration failures after a few minutes. The store repeatedly reports the error, [WARNING]: wait returned error 4 [select: (22) Invalid argument]. Changing fd_management_type to devpoll prevents this problem. Informatica is investigating this problem.
UMP proxy source elections can only occur among stores in the same topic resolution domain connected directly via peer links. Informatica is investigating this problem.
Corrected a problem that allowed ULB to reassign messages even if ump_ulb_application_set_message_max_reassignments was set to 1. The user document correctly states that by setting the flag to 1, a message will not be reassigned.
The method, getJMSRedelivered for a message always
returns false for redelivered messages when using Queue Session IDs along with the
topic's message-reassignment-timeout set to 0 (zero).
The UM configuration file specified for a queue cannot also contain source attributes for a store such as, source ume_store 127.0.0.1:14567 or source ume_store_name NYstore2.
When servicing large message retrieval requests from a queue browser, the queue may become busy enough that the receiver perceives it as unresponsive and re-registers with the queue, canceling the message retrieval request. Informatica recommends limiting large message retrievals to 1000 messages at a time, waiting for each retrieval to finish before beginning the next retrieval request
| Prev | Home | Next |
| Release UMS 5.3.5 / UMP 5.3.5 / UMQ 5.3.5 - November - 2013 | Release UMS 5.3.3 / UMP 5.3.3 / UMQ 5.3.3 - March - 2013 |
Copyright (c) 2004 - 2014 Informatica Corporation. All rights reserved.