|
| |
| Sun Java System Message Queue 3 2005Q1 Administration Guide | |
Chapter 8
Managing Administered ObjectsThe use of administered objects enables the development of client applications that are portable to other JMS providers. Administered objects encapsulate provider-specific configuration and naming information.
A Message Queue administrator typically creates administered objects for client applications to use in obtaining broker connections. A client application uses a connection to send messages to physical destinations and receive messages from physical destinations.
This chapter explains how you use the Object Manager utility (imqobjmgr) to perform these tasks. Because these tasks involve an understanding of the attributes of both the object store you are using and of the administered objects you are creating, this chapter provides background on these two topics before describing how to use imqobjmgr to manage administered objects.
This chapter contains the following sections:
About Object StoresAdministered objects are placed in a readily available object store where they can be accessed by client applications through a JNDI lookup. There are two types of object stores you can use: a standard LDAP directory server or a file-system object store.
LDAP Server Object Store
An LDAP server is the recommended object store for production messaging systems. LDAP implementations are available from a number of vendors and are designed for use in distributed systems. LDAP servers also provide security features that are useful in production environments.
Message Queue administration tools can manage object stores on LDAP servers. However, you might first need to configure the LDAP server to store java objects and perform JNDI lookups, as prescribed in the documentation for the LDAP server.
In using an LDAP server as your object store, you need to specify the attributes shown in Table 8-1. These attributes fall into the following categories:
- Initial Context: This attribute is fixed for an LDAP server object store.
- Location: Specifies the URL and directory path for storing your administered objects, as set up in the LDAP server. In particular you must check that the specified path exists.
- Security Information: Depends on the LDAP provider. You should consult the documentation provided with your LDAP implementation to determine whether security information is required on all operations or only on operations that change the stored data.
File-System Object Store
Message Queue also supports a file-system object store implementation. While the file-system object store is not fully tested and is therefore not recommended for production systems, it has the advantage of being very easy to use in development environments. Rather than setting up an LDAP server, all you must do is create a directory on your local file system.
However a file-system store cannot be used as a centralized object store for clients deployed across multiple computer nodes unless these clients have access to the directory where the object store resides. In addition, any user with access to that directory can use Message Queue administration tools to create and manage administered objects.
In using a file-system object store, you need to specify the attributes shown in Table 8-2. These attributes fall into the following categories:
- Initial Context: The value of this attribute is fixed for a file system object store.
- Location: The value of this attribute specifies the directory path for storing your administered objects. The directory must exist and have the proper access permissions for the user of Message Queue administration tools as well as the users of the client applications that will access the store.
About Administered Object AttributesMessage Queue administered objects are of two basic kinds:
Message Queue provides two administration tools for creating and managing administered objects: the command line Object Manager utility (imqobjmgr) and the GUI Administration Console. This chapter describes only how to use the command line.
The attributes of an administered object are specified using attribute-value pairs.
Connection Factory Attributes.
The configuration of a connection factory passes to all the connections that the connection factory creates on behalf of client applications. Connections are configured to define the parties involved in sending or receiving messages, to specify how the client runtime handles message flow, and to automatically set certain information for all messages sent across a connection.
There are two types of connection factory objects:
The ConnectionFactory and XAConnectionFactory objects share the same set of attributes.
A connection factory object can be created and configured by an administrator or by an application (for prototyping or testing). You set connection factory attributes using the imqobjmgr tool or the administration console.
This section describes the connection factory attributes in the following sections, which are organized by the behaviors that the attributes affect:
The attribute you are primarily concerned with is imqAddressList, which you use to specify the broker to which the client will establish a connection. Adding a Connection Factory explains how to specify attributes when you add a connection factory administered object to your object store.
For reference information about connection factory attributes, see Chapter 16, "Administered Object Attribute Reference," and the JavaDoc API documentation for the Message Queue class com.sun.messaging.ConnectionConfiguration.
Connection Handling
You use connection handling attributes to specify the message server address to which you want to connect and, if reconnection is required, to specify how many times reconnection should be attempted and the interval between attempts.
A client connects to a message server at the message server address that you specify as the value for the imqAddressList attribute. The message server address contains a broker host name, a port number, and a connection service type.
The port number can be the port where the broker’s Port Mapper resides, or the port where a specific connection service resides. If you specify the Port Mapper port, the Port Mapper dynamically assigns the port number for the connection. For complete information about specifying a message server address, see Syntax for the imqAddressList Attribute Value.
Automatic Reconnection
In a single broker environment or multi-broker cluster environment, you can set connection handling attributes that enable a client to automatically reconnect to a broker if a connection fails. You can also configure the reconnection process.
The reconnection feature provides connection failover but not data failover: persistent messages and other state information held by a failed or disconnected broker can be lost when the client is reconnected to a different broker instance.
If auto-reconnect is enabled, Message Queue persists temporary destinations when a connection fails, because clients might reconnect and access them again. After giving clients time to reconnect and use these destinations, the broker deletes the destinations.
The way that reconnection is handled depends on whether the client is connected to a single broker or to a broker that is part of a cluster. The following sections describe each of these possibilities.
Reconnecting to a Single Broker To enable a client to be automatically reconnected to a broker when a connection fails, you set the following connection factory attributes:
For full reference information about these attributes, see Connection Handling
Reconnecting to a Broker in a Cluster In a multi-broker cluster environment, automatic reconnection iterates through a list of brokers if you specify multiple addresses for the imqAddressList attribute. All brokers in the list must be installations of Message Queue Enterprise Edition.
If the client connection to the first address in the list fails, the client runtime attempts to reconnect the client to another broker in the list. If that attempt fails, the client runtime continues through the list until it is able to reconnect the client.
If no attempt is successful, the client runtime cycles through the list for a specified number of times until it finds an available broker or fails to find one. The setting of the imqAddressListBehavior attribute determines whether the broker chosen for reconnection is next in the sequence of addresses provided in the address list, or whether it is randomly chosen from that list.
To enable a client to be reconnected to a broker in a cluster, use the following attributes:
- imqReconnectEnabled. Enables the automatic reconnect behavior.
- imqReconnectAttempts. Specifies how many times to try each broker address before passing to the next.
- imqReconnectInterval. Specifies how long to wait between attempts.
- imqAddressListIterations . Specifies the number of times to iterate through the list.
- imqAddressListBehavior. Specifies whether connection attempts are in the order of addresses in the address list or in a random order.
For full reference information about these attributes, see Connection Handling.
Connection Ping
The imqPingInterval attribute specifies the frequency of a ping operation from the client runtime to the broker. By periodically testing the connection, the client runtime can preemptively detect a failed connection. If the ping operation fails, the client runtime throws an exception to the client application’s exception listener object. If the application does not have an exception listener, the application’s next attempt to use the connection fails.
Use of the ping is especially important for consumer client applications that wait to receive messages and do not send messages. Such an application would not otherwise know when a connection fails. A client that produces infrequent messages can also benefit from this feature, because it could handle a failed connection before needing to send a message.
By default, the ping interval is set at 30 seconds. A value of -1 disables the ping operation.
The response to a broken connection is operating system-specific. For example, on some operating systems, a ping reports a failure immediately. Other operating systems might continue trying to establish the connection to the broker, buffering successive pings until the ping is successful or the buffer overflows.
For full reference information about the imqPingInterval attribute, see Connection Handling.
Client Identification
Message Queue defines a set of connection factory attributes to support client authentication and the setting of a unique client ID, which is required for durable subscribers.
Clients attempting to connect to the broker must be authenticated. If the client does not specify a user name or password when creating the connection, one of the following happens:
- If the connection factory attributes imqDefaultUsername and imqDefaultPassword are not set, the client runtime passes the values guest/guest to the broker, and the broker authenticates the client using those values.
The user repository is shipped with the entry guest/guest, so the client will obtain the connection.
- If the connection factory attributes imqDefaultUsername and imqDefaultPassword attributes are set, the client runtime passes those values to the broker, and the broker authenticates the client using those values.
If that user/password pair is in the user repository, the client gets the connection.
This scheme allows any user to get a connection, which is convenient for development and testing. In a production system, access to connections should be limited to users that have been added to the user repository.
In addition to broker authentication of clients that request a connection, the JMS specification requires that a connection provides a unique client identifier when where state has to be maintained for the client. Message Queue uses the client ID to keep track of its durable subscribers. If a durable subscriber becomes inactive, the broker retains messages for that subscriber and delivers them when the subscriber becomes active again. The broker identifies the subscriber by means of its client ID.
You can set ClientID administratively, or clients can set it programmatically. If multiple clients obtain connections from the same connection factory object, set ClientID for a connection factory. Message Queue can then provide a unique ClientID for each connection obtained from that factory.
To ensure a unique ClientID value, set the imqConfiguredClientID attribute using the following format:
imqConfiguredClientID=${u}string
The ${u} must be the first four characters of the attribute value. If anything other than “u” is encountered, a JMS exception occurs upon connection creation.
The value for string is any value that you want to associate with a connection produced by this connection factory, such as Xconn. During the user authentication stage, Message Queue substitutes u:userName for u. For example, if the user associated with the connection is Athena and the string specified for the connection is ${u}Xconn, the ClientID will be u:AthenaXconn.
This scheme ensures that each connection produced by a connection factory, although identical in every other way, will contain a unique ClientID.
There is one case in which this scheme will not work: If two clients obtain a connection using a default user name such as guest, each will have a ClientID with the same ${u} component. At runtime, the first client to request the connection will get it; the second will not because MQ cannot create a connection with a non-unique ClientID.
You can set the imqDisableSetClientID attribute to disallow clients that use the connection factory from programmatically changing the configured client ID.
You must set the imqConfiguredClientID attribute for durable subscriptions, unless the application code uses the setClientId() method.
In summary, these are the attributes that affect client identification:
- imqDefaultUsername. Specifies the default user name that will be used to authenticate with the broker when the client does not specify a user name in creating the connection.
- imqDefaultPassword. Specifies the default password that will be used to authenticate with the broker when the client does not specify a password in creating the connection..
- imqConfiguredClientID. Specifies the value of an administratively configured client ID.
- imqDisableSetClientID. Specifies whether a client who uses the connection factory can change the client ID programmatically.
For full reference information about these attributes, see Client Identification.
Reliability And Flow Control
Messages sent and received by clients and control messages used by Message Queue pass over the same client-broker connection. As a result, delays can occur in the delivery of control messages, such as broker acknowledgments, if they are held up by the delivery of JMS messages.
You can set connection factory attributes that allow you to manage the flow of control messages relative to the flow of client messages. Controlling the flow of the two types of messages involves a compromise between reliability and throughput. For a discussion of how you use these attributes to manage flow control and reliability, see Client Runtime Message Flow Adjustments
The following attributes affect the flow of client and control messages:
- imqAckTimeout. Specifies, in milliseconds, the maximum time that the client runtime will wait for any broker response.
- imqConnectionFlowCount. Specifies the number of JMS messages in a metered batch.
- imqConnectionFlowLimitEnabled. Limits message flow at the connection level.
- imqConnectionFlowLimit. Specifies a limit on the number of messages that can be delivered over a connection and buffered in the client runtime, waiting to be consumed.
- imqConsumerFlowLimit. Specifies a per-consumer limit on the number of messages that can be delivered over a connection and buffered in the client runtime, waiting to be consumed.
- imqConsumerFlowThreshold. Specifies, as a percentage of imqConsumerFlowLimit, the number of messages for each consumer to buffer in the client runtime, below which delivery of messages for a consumer will resume.
For full reference information about these attributes, see Reliability and Flow Control.
Queue Browser Behavior and Server Session
These attributes affect client queue browsing:
- imqQueueBrowserMaxMessagesPerRetrieve. Specifies the maximum number of messages that a client retrieves at one time, when browsing the contents of a queue destination.
- imqQueueBrowserRetrieveTimeout. Specifies how long the client waits to retrieve messages, when browsing the contents of a queue destination.
- imqLoadMaxToServerSession.For JMS application server facilities, specifies whether a Message Queue ConnectionConsumer loads up to the maxMessages number of messages into a ServerSession's session, or loads a single message at a time.
For full reference information about these attributes, see Queue Browser Behavior and Server Session.
JMS-Defined Properties Support
You can use connection factory attributes to automatically set JMS-defined properties on messages that a connection produces. The JMS properties are defined in the JMS specification, at http://java.sun.com/products/jms/docs.html.
Use the following attributes to set JMS-defined properties:
- imqSetJMSXUserID. For produced messages, specifies whether Message Queue sets the JMS-defined property JMSXUserID (identity of user sending the message).
- imqSetJMSXAppID. For produced messages, specifies whether Message Queue sets the JMS-defined property JMSXAppID (identity of application sending the message).
- imqSetJMSXProducerTXID. For produced messages, specifies whether Message Queue sets the JMS-defined property JMSXProducerTXID (transaction identifier of the transaction that produced the message).
- imqSetJMSXConsumerTXID. For consumed messages, specifies whether Message Queue should set the JMS-defined property JMSXConsumerTXID (transaction identifier of the transaction that consumed the message).
- imqSetJMSXRcvTimestamp. For consumed messages, specifies whether Message Queue should set the JMS-defined property, JMSXRcvTimestamp (the time the message is delivered to the consumer).
For full reference information about these attributes, see JMS-Defined Properties Support.
Message Header Overrides
You can override JMS message header fields that specify the persistence, lifetime, and priority of messages by setting attributes of a connection factory. The settings are used for all messages produced by connections obtained from the connection factory.
The values in the following JMS fields can be overridden:
For more information about these fields, see the JMS specification at http://java.sun.com/products/jms/docs.html.
Because overriding message headers could interfere with application requirements, use this feature only in consultation with application users or designers.
The following list contains the connection factory attributes that deal with message overrides. Most of these attributes are paired. For each pair, the first attribute specifies whether a specified header field can be overridden, and the second attribute specifies the override value.
- imqOverrideJMSDeliveryMode and imqJMSDeliveryMode.. The first attribute specifies whether a client-set JMSDeliveryMode field can be overridden; the second attribute specifies its override value.
- imqOverrideJMSExpiration and imqJMSExpiration. The first attribute specifies whether a client-set JMSExpiration field can be overridden; the second attribute specifies its override value.
- imqOverrideJMSPriority and imqJMSPriority. The first attribute specifies whether a client-set JMSPriority field can be overridden; the second specifies attribute its override value.
- imqOverrideJMSHeadersToTemporaryDestinations. Specifies whether overrides apply to temporary destinations.
For full reference information about these attributes, see Message Header Overrides.
Destination Administered Object Attributes
The destination administered object that identifies a physical topic or queue destination has the attributes listed in Table 16-1. The section, Adding a Topic or Queue, explains how you specify these attributes when you add a destination administered object to your object store.
The attribute you are primarily concerned with is imqDestinationName. This is the name you assign to the physical destination that corresponds to the topic or queue administered object. You can also provide a description of the destination that will help you distinguish it from others that you might create to support many applications.
For more information, see the JavaDoc API documentation for the Message Queue class com.sun.messaging.DestinationConfiguration.
Using the Object Manager Utility (imqobjmgr)The Object Manager utility allows you to create and manage Message Queue administered objects. Using this utility, you can perform the following tasks:
For reference information about the syntax, subcommands, and options of the imqobjmgr command, see Chapter 13, "Command Reference." The following section describes information that you need to provide when working with any imqobjmgr subcommand.
Required Information
When performing most tasks related to administered objects, you must specify the following information as options to imqobjmgr subcommands:
The allowed types are shown in Table 13-11.
- Administered object attributes (needed especially for the add and update subcommands):
- For destinations: The name of the physical destination on the broker. This is the name that was specified with the -n option to the imqcmd create dst subcommand. If you do not specify the name, the default name of Untitled_Destination_Object will be used.
- For connection factories: The most commonly used attribute is the address list (imqAddressList) specifying the message server addresses (one or more) to which the client will attempt to connect. If you do not specify this information, the local host and default port number (7676) are used, meaning the client will attempt a connection to a broker on port 7676 of the local host. The section Adding a Connection Factory explains how you specify object attributes.
For additional attributes, see Connection Factory Attributes..
- Object store attributes
This information depends on whether you are using a file-system store or LDAP server, but must include the following attributes:
- The type of JNDI implementation (initial context attribute). For example, file-system or LDAP.
- The location of the administered object in the object store (provider URL attribute), that is, its “folder” as it were.
- The user name, password, and authorization type, if any, required to access the object store.
For more information about object store attributes see LDAP Server Object Store and File-System Object Store.
Using Command Files
The imqobjmgr command allows you to specify the name of a command file that uses java property file syntax to represent all or part of the imqobjmgr subcommand clause.
Using a command file with the Object Manager utility (imqobjmgr) is especially useful to specify object store attributes, which are likely to be the same across multiple invocations of imqobjmgr and which normally require a lot of typing. Using an command file can also allow you to avoid a situation in which you might otherwise exceed the maximum number of characters allowed for the command line.
The general syntax for an imqobjmgr command file is as follows (the version property reflects the version of the command file and not of the Message Queue product—it is not a command line option—and its value must be set to 2.0):
As an example of how you can use an command file, consider the following imqobjmgr command:
imqobjmgr add
-t qf
-l "cn=myQCF"
-o "imqAddressList=mq://foo:777/jms"
-j "java.naming.factory.initial=
com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=
ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=
uid=fooUser, ou=People, o=imq"
-j "java.naming.security.credentials=fooPasswd"
-j "java.naming.security.authentication=simple"
This command can be encapsulated in a file, say MyCmdFile, that has the following contents:
version=2.0
cmdtype=add
obj.type=qf
obj.lookupName=cn=myQCF
obj.attrs.imqAddressList=mq://foo:777/jms
objstore.attrs.java.naming.factory.initial=\
com.sun.jndi.ldap.LdapCtxFactory
objstore.attrs.java.naming.provider.url=\
ldap://mydomain.com:389/o=imq
objstore.attrs.java.naming.security.principal=\
uid=fooUser, ou=People, o=imq
objstore.attrs.java.naming.security.credentials=fooPasswd
objstore.attrs.java.naming.security.authentication=simple
You can then use the -i option to pass this file to the Object Manager utility (imqobjmgr):
imqobjmgr -i MyCmdFile
You can also use the command file to specify some options, while using the command line to specify others. This allows you to use the command file to specify parts of the subcommand clause that is the same across many invocations of the utility. For example, the following command specifies all the options needed to add a connection factory administered object, except for those that specify where the administered object is to be stored.
In this case, the file MyCmdFile would contain the following definitions:
version=2.0
objstore.attrs.java.naming.factory.initial=\
com.sun.jndi.ldap.LdapCtxFactory
objstore.attrs.java.naming.provider.url=\
ldap://mydomain.com:389/o=imq
objstore.attrs.java.naming.security.principal=\
uid=fooUser, ou=People, o=imq
objstore.attrs.java.naming.security.credentials=fooPasswd
objstore.attrs.java.naming.security.authentication=simple
Additional examples of command files can be found at the following location:
Adding and Deleting Administered ObjectsThis section explains how you add administered objects for connection factories and topic or queue destinations to the object store.
Note
The Object Manager utility (imqobjmgr) lists and displays only Message Queue administered objects. If an object store should contain a non-Message Queue object with the same lookup name as an administered object that you wish to add, you will receive an error when you attempt the add operation.
Adding a Connection Factory
To enable client applications to obtain a connection to the broker, you add an administered object that represents the type of connections the client applications want: a topic connection factory or a queue connection factory
To add a queue connection factory, use a command like the following:
imqobjmgr add
-t qf
-l "cn=myQCF"
-o "imqAddressList=mq://myHost:7272/jms"
-j "java.naming.factoryinitial=
com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=
uid=fooUser, ou=People, o=imq"
-j "java.naming.security.credentials=fooPasswd"
-j "java.naming.security.authentication=simple"
The preceding command creates an administered object whose lookup name is cn=myQCF and which connects to a broker running on myHost and listens on port 7272. The administered object is stored in an LDAP server. You can accomplish the same thing by specifying an command file as an argument to the imqobjmgr command. For more information, see Using Command Files.
Note
Naming Conventions: If you are using an LDAP server to store the administered object, it is important that you assign a lookup name that has the prefix “cn=” as in the example above (cn=myQCF). You specify the lookup name with the -l option. You do not have to use the cn prefix if you are using a file-system object store, but do not use lookup names that have a “/” in them. See Table 8-3.
Table 8-3 Naming Convention Examples
Object Store Type
Good Name
Ban Name
LDAP server
cn=myQCF
myQCF
file system
myTopic
myObjects/myTopic
Adding a Topic or Queue
To enable client applications to access physical destinations on the broker, you add administered objects that identify these destinations, to the object store.
It is a good practice to first create the physical destinations before adding the corresponding administered objects to the object store. Use the Command utility (imqcmd) to create the physical destinations on the broker that are identified by destination administered objects in the object store. For information about creating physical destinations, see Getting Information About Connections.
The following command adds an administered object that identifies a topic destination whose lookup name is myTopic and whose physical destination name is TestTopic. The administered object is stored in an LDAP server.
imqobjmgr add
-t t
-l "cn=myTopic"
-o "imqDestinationName=TestTopic"
-j "java.naming.factory.initial=
com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=
ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=
uid=fooUser, ou=People, o=imq"
-j "java.naming.security.credentials=fooPasswd"
-j "java.naming.security.authentication=simple"
This is the same command, only the administered object is stored in a Solaris file system:
imqobjmgr add
-t t
-l "cn=myTopic"
-o "imqDestinationName=TestTopic"
-j "java.naming.factory.initial=
com.sun.jndi.fscontext.RefFSContextFactory"
-j "java.naming.provider.url=
file:///home/foo/imq_admin_objects"
In the LDAP server case, as an example, you could use an command file, MyCmdFile, to specify the subcommand clause. The file would contain the following text:
version=2.0
cmdtype=add
obj.type=t
obj.lookupName=cn=myTopic
obj.attrs.imqDestinationName=TestTopic
objstore.attrs.java.naming.factory.initial=
com.sun.jndi.fscontext.RefFSContextFactory
objstore.attrs.java.naming.provider.url=
file:///home/foo/imq_admin_objects
objstore.attrs.java.naming.security.principal=
uid=fooUser, ou=People, o=imq
objstore.attrs.java.naming.security.credentials=fooPasswd
objstore.attrs.java.naming.security.authentication=simple
Use the -i option to pass the file to the imqobjmgr command:
imqobjmgr -i MyCmdFile
Note
If you are using an LDAP server to store the administered object, it is important that you assign a lookup name that has the prefix “cn=” as in the example above. You specify the lookup name with the -l option. You do not have to use this prefix if you are using a file-system object store.
Adding a queue object is exactly the same, except that you specify q for the -t option.
Deleting Administered Objects
Use the delete subcommand to delete an administered object. You must specify the lookup name of the object, its type, and its location.
The following command deletes an administered object for a topic whose lookup name is cn=myTopic and which is stored on an LDAP server.
imqobjmgr delete
-t t
-l "cn=myTopic"
-j "java.naming.factory.initial=
com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=
ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=
uid=fooUser, ou=People, o=imq"
-j "java.naming.security.credentials=fooPasswd"
-j "java.naming.security.authentication=simple"
Listing Administered ObjectsUse the list subcommand to get a list of all administered objects or to get a list of all administered objects of a specific type. The following sample code assumes that the administered objects are stored in an LDAP server.
The following command lists all objects.
imqobjmgr list
-j "java.naming.factory.initial=
com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=
ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=
uid=fooUser, ou=People, o=imq"
-j "java.naming.security.credentials=fooPasswd"
-j "java.naming.security.authentication=simple"
The following command lists all objects of type queue.
imqobjmgr list
-t q
-j "java.naming.factory.initial=
com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=
ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=
uid=fooUser, ou=People, o=imq"
-j "java.naming.security.credentials=fooPasswd"
-j "java.naming.security.authentication=simple"
Getting Information About a Single ObjectUse the query subcommand to get information about an administered object. You must specify the object’s lookup name and the attributes of the object store containing the administered object (such as initial context and location).
In the following example, the query subcommand is used to display information about an object whose lookup name is cn=myTopic.
imqobjmgr query
-l "cn=myTopic"
-j "java.naming.factory.initial=
com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=
ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=
uid=fooUser, ou=People, o=imq"
-j "java.naming.security.credentials=fooPasswd"
-j "java.naming.security.authentication=simple"
Updating Administered ObjectsYou use the update command to modify the attributes of administered objects. You must specify the lookup name and location of the object. You use the -o option to modify attribute values.
This command changes the attributes of an administered object that represents a topic connection factory:
imqobjmgr update
-t tf
-l "cn=MyTCF"
-o imqReconnectAttempts=3
-j "java.naming.factory.initial=
com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=
ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=
uid=fooUser, ou=People, o=imq"
-j "java.naming.security.credentials=fooPasswd"
-j "java.naming.security.authentication=simple"