Persisted messages without durable subscriptions

Does weblogic JMS support PERSISTED MESSAGES without durable subscriptions. As per jms spec message persistence does make sense even without durable subscriptions in case when the JMS server fails before a message is sent and acknowledged.
          "A JMS provider must deliver a PERSISTENT message once-and-only-once. This means a JMS provider failure must not cause it to be lost and it must not deliver it twice."
          This implies that a persisted message will be persisted before sending and if JMS server fails, it resends the message to available consumers when server is back up and has nothing to do with durable/non-durable subscriptions.
          Please let me know what you guys think and if it is supported in weblogic JMS.
          Thanks,
          -Raj

- Topics require durable subcriptions to persist messages. This is a standard part of the JMS API. Nondurable subscribers have absolutely no need for persistence by definition - as such subscriptions exist solely for the life of the client's connection.
          - And yes, queues support persistence. This is required by the JMS spec, which BEA fully implements.
          - True "exactly-once" behavior usually requires the use of transactions in conjunction with JMS. This ensures that the message being processed and any related application work either atomically all fails or all succeeds.
          The above applies to all JMS vendors.
          Tom, BEA

Similar Messages

Durable subscriptions with UMS?

Is it possible to create durable subscirptions for a topic using UMS?
Or if not, can I use UMS to read from a durable subscription if I create and manage it with another JMS client application?
Thanks for any help

Doing some more research, I found messaging patterns that do what I'm looking for without durable subscriptions.
Apache's ActiveMQ uses something called [Virtual Topics|http://activemq.apache.org/virtual-destinations.html] that allows forwardig messages to multiple queues so that every consumer can read messages from its "own" durable queue without managing unique client IDs.
OpenAMQ with RestMS works similar. Messages are send to a write-only "feed" and forwarded to one ore more read-only "pipes". Again, each consumer can read from its own queue/pipe.
Is there something similar in OpenMQ?
M.S.

Do I really need two connection pools when using two durable subscriptions?

I have a Spring daemon which takes messages from two different topics and stores them in a database.
What irritates me is that I can't get it to work with a single connection pool. I get a message that I can't create durable subscriptions without a unique client id on the connection. It's not enough that the client id be set on the listener container, I have to set it on the underlying ConnectionFactory. I though this was some kind of glitch with openMQ but activeMQ gives me exactly the same behaviour.
This is the important part of the config
    <bean id="realCon" class="org.apache.activemq.ActiveMQConnectionFactory" p:brokerURL="discovery:(multicast://default?group=live)"
    p:clientID="DB_RECORD_CLIENT"/>
    <bean id="realCon2" class="org.apache.activemq.ActiveMQConnectionFactory" p:brokerURL="discovery:(multicast://default?group=live)"
    p:clientID="DB_LOG_CLIENT"/>
    <bean id="jmsConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory"
    p:targetConnectionFactory-ref="realCon"/>
    <bean id="jmsConnectionFactory2" class="org.springframework.jms.connection.CachingConnectionFactory"
    p:targetConnectionFactory-ref="realCon2"/>
    <bean id="ocsMessageListener" class="com.cc.mer.ordercatcher.MessageReceived"/>
    <bean id="logMessageListener" class="com.cc.mer.ordercatcher.LogMessageReceived"/>
    <jms:listener-container
        connection-factory="jmsConnectionFactory"
        destination-type="durableTopic"
        transaction-manager="transactionManager"
        acknowledge="transacted"
        >
        <jms:listener ref="ocsMessageListener" destination="OCS_RELAYED"
                      subscription="ocs.db.recording" />
    </jms:listener-container>
    <jms:listener-container
        connection-factory="jmsConnectionFactory2"
        destination-type="durableTopic"
        transaction-manager="transactionManager"
        acknowledge="transacted"
        >
        <jms:listener ref="logMessageListener" destination="OCS_LOG"
                      subscription="ocs.log.recording" />
    </jms:listener-container>

Thank you all for your replies.
Yesterday, I went back to BestBuy and returned the Gigabit Ethernet Switch and exchanged it for a Belkin Share Max N300 router. I chose this one because I want to use the router in WIRED mode and this had a 10/100/1000Mbps Gigabit Ethernet capability. Most other routers that I looked at only had 10/100Mbps. I also liked that it had two USB ports.
I had to call Belkin tech support because the installer from the included CD would not install the software. Nor would the installer that I downloaded from their web site. I ended up actually having to be taken to the IP address' web site and from there I was able to configure everything.
Although it took me a few hours to get all my other wireless devices onto my wireless network (I have a couple of Airport Express(es) for running "Airplay," and a wifi dongle on my TV), things now seem to be working fine.

Durable Subscription with MDB in Weblogic 7.0

Hi,
          I am using WLS 7.0 as the JMS Provider and as the EJB Container(no
          clustering). My question is do I need MDB with durable subscription. I
          cannot think of a instance when the container will be down but JMS
          provider is still running if I am using WLS as both container and JMS
          provider.
          One instance i can think of is if the MDB is not deployed (upon a new
          release of our application, for some strange reason) but rest of the
          application is deployed then the producers will produce messages for
          the off-line subscriber.
          If I assume that the above is not likely to happen, can you think of
          any compelling reason for me to use MDB with durable subcription .
          Thanks for your input.
          ssahu


1) The MDB should only specify "durable" if it is receiving from a
          topic. Durable does not apply to queues.
          2) If messages are non-persistent, then you likely don't need durable.
          As these messages don't survive the shutdown...
          3) Making it durable helps with race-conditions during shutdown or
          startup where messages are sent but the MDB isn't up. It also helps
          with the condition where shutdown occurs before the MDB finishes
          processing all of its messages. (So Durable ensures that the
          MDB does not miss a message. It may even help in the non-persistent
          case if is possible that the MDB is temporarily undeployed (by you)
          while the server is up.
          [email protected] wrote:
          > Hi,
          > I am using WLS 7.0 as the JMS Provider and as the EJB Container(no
          > clustering). My question is do I need MDB with durable subscription. I
          > cannot think of a instance when the container will be down but JMS
          > provider is still running if I am using WLS as both container and JMS
          > provider.
          > One instance i can think of is if the MDB is not deployed (upon a new
          > release of our application, for some strange reason) but rest of the
          > application is deployed then the producers will produce messages for
          > the off-line subscriber.
          >
          > If I assume that the above is not likely to happen, can you think of
          > any compelling reason for me to use MDB with durable subcription .
          >
          > Thanks for your input.
          >
          > ssahu

InvalidClientIdException while creating Durable subscription in weblogic

Hi,
We have scenario to create a durable subscription for an MDB. Here application in weblogic is a subscriber to a Topic present on the Progress Sonic. For integrating to independent platforms we are using Foreign Server mechanism under JMS Modules.
For creating durable subscription, we have changed the MDB code . Below is the MDB code,
package com.test;
import java.util.Enumeration;
import javax.annotation.Resource;
import javax.annotation.Resources;
import javax.ejb.MessageDriven;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;
import javax.ejb.ActivationConfigProperty;
* Message-Driven Bean implementation class for: TestMDB
@MessageDriven(description = "mdb for Airline Schedule Change MDB",
name = "AirlineScheduleMDB",
activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Topic"),
@ActivationConfigProperty(propertyName = "subscriptionDurability",
propertyValue = "Durable")
@TransactionManagement(value = TransactionManagementType.CONTAINER)
@Resources( { @Resource(name = "ConnectionFactoryRef",
mappedName = "TopicConnectionFactory",
type = javax.jms.ConnectionFactory.class) })
public class TestMDB implements MessageListener {
* @see MessageListener#onMessage(Message)
@TransactionAttribute(value = TransactionAttributeType.NOT_SUPPORTED)
public void onMessage(Message message) {
System.out.println("Inside message : ");
try {
Enumeration<Object> messageProperty = message.getPropertyNames();
System.out.println("The request : "+message);
if(message != null){
System.out.println("TestMDB : onMessage : Start");
}else{
System.out.println("Received Input message is empty");
} catch (Exception e) {
System.out.println("Exception Occurred in TestMDB : ");
e.printStackTrace();
System.out.println("TestMDB : onMessage : End.Time taken is :");
Also the following change was included in the weblogic-ejb-jar.xml.
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-ejb-jar
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>TestMDB</ejb-name>
<message-driven-descriptor>
<pool>
<initial-beans-in-free-pool>1</initial-beans-in-free-pool>
</pool>
<destination-jndi-name>DurableJNDI</destination-jndi-name>
<connection-factory-jndi-name>TopicConnectionFactory</connection-factory-jndi-name>
<jms-polling-interval-seconds>30</jms-polling-interval-seconds>
<generate-unique-jms-client-id>true</generate-unique-jms-client-id>
<jms-client-id>DurableTest</jms-client-id>
</message-driven-descriptor>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
Exception we got :
<03-Apr-2012 18:11:02 o'clock UTC> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: TestMDB is unable to connect to the JMS destination: DurableJNDI. The Error was:
javax.jms.InvalidClientIDException: Invalid client id: DurableTest_drdevwls_TestDomain-wls1_CLEARCF.jarTestMDB
Weblogic is automatically creating a unique id based on the combination of Adminserver/Managedserver/Projectname etc.
However the id created by weblogic seems to have a dot(.) which as per Sonic spec is an invalid character.
eg:- DurableTest_test_domain_AdminServer_CLEARCF.jarTestMDB
Hence we changed the parameter to false and provided our own value.
<generate-unique-jms-client-id>false</generate-unique-jms-client-id>
<jms-client-id>DurableTest</jms-client-id>
At this point of time we were able to see that MDB have created a Durable subscription successfully and it worked as expected.
However when we tried to scale this change to multiple managed servers, there were errors thrown from sonic side.
javax.jms.JMSException: [129] progress.message.client.EUserAlreadyConnected: Administrator/$DURABLE$DurableTest$DurableTest
So we cannot have same clientid for multiple clients(managed server). We arent sure how to proceed with this.
We need to find a way to remove the dot from the dynamic id weblogic creates.
Any help on this is highly appreciated.

Hi Tom,
We have found the solution to this problem and thanks for your suggestion that has partially helped us in solving the problem.
As you have suggested we have defined client-id on the connection factory however we will be having only connection factory instead of multiple with different client-ID's.
Along with the client-id configured at the connection factory level we are now setting the attributes generate-unique-client-id as true at the weblogic end.
By doing this way, I assume that weblogic while making the durable subscription connection is passing the uniquely generated client ID (which has dots '.' included in it ) as subscription name and client-id will be same, that is defined on the connection factory.
A question may arise that - 'why is sonic accepting subscription name with dots but not the client-id ?' - When observed from the sonic end the dots in the subscription name are replaced by '@@@' .
Sonic need to answer the question of why the dots are being replaced for subscription name but not for client-id.
Regards,
Bharat K

JMS Specification Question regarding persistent messages and reliability.

In section 6.15 of the JMS Specification, titled reliability it is stated that:
"When all messages for a topic must be received, a durable subscriber should be used. JMS insures that messages published while a durable subscriber is inactive are retained by JMS and delivered when the subscriber subsequently becomes active.
Nondurable subscribers should be used only when missed messages are tolerable."
Then in a table following the above text it states that a nondurable subscriber on a topic flowing persistent messages will receive a message "once-and-only-once (missed if inactive)."
To me this implies that if a nondurable subscriber is active, it is guaranteed to receive all persistent messages published to the topic while it is active. However there seems to be some ambiguity about what it means to be "active." Does active mean subscribed, does it mean subscribed and not busy processing messages, something else?
I ask this because I'm seeing a somewhat slow subscriber not receiving all persistent messages published while it is subscribed. This was surprising to me, given my interpretation of this reliability clause, so I'm wondering if I have not interpreted it correctly in this case.
Could anyone fill me in, particularly if you had something to do with writing the spec or can point me to the rationale behind this portion of the spec?
Thanks,
Jeff Singer

I am looking at the JMS 1.1 Spec version 1.1 April 12, 2002.
Section 4.10 "Reliabilty" has what reads to me as kind of a CYA statement that the contributing JMS providers got inserted. It reads:
"A JMS provider may have resource restrictions that limit the number of messages that can be held for high-volume destinations or non-responsive clients. If messages are dropped due to resource limits, this is usually a serious administrative issue that needs attention. Correct functioning of JMS requires that clients are responsive and that adequate resources to service them are available.
+
+
+Once-and-only-once message delivery, as described in this specification, has the important caveat that it does not cover message destruction due to message expiration or other administrative destruction criteria. It also does not cover loss due to resource restrictions. Configuration of adequate resources and processing power for JMS applications is the job of administrators, who must be aware of their JMS provider's reliability features."
+

My JMS 2 wish list - Part 4, durable subscriptions

I attended the JavaOne 2010 session on future JMS evolutions. During the session I described some current limitations or issues I'd like to be solved in a portable way. I've been adviced to share the issues to get feedback from the community. I will post each issue in a dedicated thread.
Issue 4 - How durable are durable topic subscriptions?
Non durable subscribers receive topic messages only if they are active at the time when the message is received and processed by the JMS engine. Durable subscribers are more complicated, they receive messages if the durable subscription is active when the message is received and processed by the JMS engine.
How do I know when messages are kept or discarded? Simply put, what is the lifecycle of the subscription?
When using synchronous receptions or message listeners, the durable subscription lifecycle is managed by the developper using Session:createDurableSubscriber and Session:unsubscribe.
When using MDB, the durable subscription lifecycle is unspecified and is application server dependant.
With JBoss 4.2, the subscription lifecyle is the same than the MDB. This means that if the application is redeployed (for example copy the new .ear over the old one in the deploy folder), there is a time frame when the subscription in non existent, so messages are lost.
WebLogic 10 also seems to associate the subscription lifecycle to the MDB. WebLogic 10 offers a flag, "durable-subscription-deletion", to allow or not the durable subscription deletion when the MDB is undeployed or removed. True means that when the application is redeployed the subscription is deleted and messages are lost. When false is used (it is the default value) the subscription remains even when the MDB is undeployed. I hope this does not mean that if we permanently undeploy the application, the subscription will stay and messages will continue to stack.
With WebSphere 6 the situation is different. The subscription is not associated to the MDB but to an activation spec that is an administred object. The MDB is merely a client of the activation spec. This way messages are kept as long as the activation spec is active, regardless of application starts/stops/redeploys/etc. Messages are not lost.
We need a portable way to use durable topics subscriptions.

gimbal2 wrote:
A portable solution would be useful.You could already do it now by leveraging the Timer functionality that has been part of the EJB spec since JEE 1.4. In stead of sending the message directly, let the timer do it after the delay you specify. That would make it portable with current tech.
I can't be sure what other implications that might have though, such as in the area of performance and resource usage - I can imagine you wouldn't want to use a timer when you need to send large volumes of messages.In the original requirement, the message is put in the queue immediately by a call to queuesender.send(message) and there's a delivery in delay to a consumer.
Whereas in this solution, the delay is in the message delivery to the queue itself.
IMHO there's a subtle but important difference here.What would for example happen if posting the message to the queue is in the scope of a distributed JTA transaction? You can definitely include the timer call to be in the scope of the transaction, but now you will have to account for the fact and there may be an error when the message is delivered which has to be handled explicitly. In the original scenario the tx would automatically rollback.
cheers,
ram.

Topic with Durable Subscription Questions...

          Hello all,
          The scenario: WL 7.0 - sp2, a clustered environment. I have a JMS Topic which
          has one MsgBean that is Durable and one MsgBean that is non-durable consuming
          messages off this Topic. Both MsgBeans are deployed on all machines in the cluster,
          and the server (which contains the topic) is targetted to one machine.
          The issue that I am experiencing is that the DurableMsgBean can not connect to
          the jms topic, but the non-durable one gets its messages all the time.
          Any ideas/suggestions?
          C.


Hi,
          The durable subscriber name is derived from the descriptor's ejb name,
          and only one consumer may attach to a particular durable subscription
          at a time. I've attached some notes that should help you out, please
          excuse the jumbled formatting.
          Let me know if this helps,
          Tom, BEA
          The durable subscription is uniquely identified within a cluster by a
          combination of "connection-id" and "subscription-id". Only one active
          connection may use a particular "connection-id" within a WebLogic cluster.
          The durable subscription id, which must be unique on its topic, comes from:
          1) <jms-client-id>MyClientID</jms-client-id>
          (the weblogic dtd)
          2) if (1) is not set then the client-id
          comes from the ejb name.
          The connection id comes from:
          1) The "ClientId" attribute configured on the WebLogic
          connection factory.
          This defaults to null. Note that if the ClientId is set on
          a connection
          factory, only one connection created by the factory
          may be active at a time.
          2) If (1) is not set, then, as with the subscriber-id,
          the connection-id is derived from jms-client-id descriptor attribute:
          <jms-client-id>MyClientID</jms-client-id>
          (the weblogic dtd)
          3) If (1) and (2) are not set, then, as with the subscriber-id,
          the connection-id is derived from the ejb name.
          Work-around:
          A) Create a custom connection-factory for each server:
          1) configure "JNDIName" to the same value across all servers
          ("myMDBCF" in this example)
          2) configure "ClientId" to a unique value per server
          3) enable "UserTransactionsEnabled"
          4) enable "XAConnectionFactoryEnabled"
          5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
          6) target the CF at a single WebLogic server
          (Number 5 is required for non-transactional topic MDBs)
          B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's
          connection factory to the JNDI name of the custom connection factories
          configured in (A). Optionally, also specify the subscriber-id via the
          jms-client-id attribute.
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>exampleBean</ejb-name>
          <message-driven-descriptor>
          <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
          <jms-client-id>myClientID</jms-client-id>
          </message-driven-descriptor>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          C) Target the application at the same servers that have the custom
          connection factories targeted at them.
          Notes/Limitations:
          1) If the MDB is moved from one server to another, the MDB's
          corresponding connection-factory must be moved with it.
          2) This work-around will not work if the destination is not in the same
          cluster as the MDB. (The MDB can not use the local connection factory,
          which
          contains the connection-id, as connection factories do not work unless they
          are in the same cluster as the destination.)
          3) This work-around will not work for non-WebLogic JMS topics.
          csw wrote:
          > Hello all,
          >
          > The scenario: WL 7.0 - sp2, a clustered environment. I have a JMS Topic which
          > has one MsgBean that is Durable and one MsgBean that is non-durable consuming
          > messages off this Topic. Both MsgBeans are deployed on all machines in the cluster,
          > and the server (which contains the topic) is targetted to one machine.
          >
          > The issue that I am experiencing is that the DurableMsgBean can not connect to
          > the jms topic, but the non-durable one gets its messages all the time.
          >
          > Any ideas/suggestions?
          >
          > C.
          >

Using MDBs for durable subscriptions

I need to be able to deploy my MDB as a durable subscriber i.e I have my MDB ubscribing to a Topic. For some reason if the application hosting the MDB(message driven bean) fails, I would like the JMS provider to republish all the messages that were already in the Topic in addition to those messages which might have been published when the MDB application was down.
I am trying to achieve this using Weblogic 7.0. The weblogic documentation says that messages will not be accumulated if the MDB using durable subscriptions is not deployed(which would be the case when the MDB application failed).
Any ideas on how I could design around this shortcoming within WLS?
Thanks
Ramdas

The WLS documentation for MDBs says :
"If your bean will demarcate its own transaction
boundaries, set the acknowledge-mode sub-element to
specify the JMS acknowledgment semantics to use. This
element has two possible values: AUTO_ACKNOWLEDGE (the
default) or DUPS_OK_ACKNOWLEDGE."Okay, I missed the part where you were specifying WLS. In the case quoted above, you will have to explicitly rollback the transaction and make sure that your MDB is set to transaction "Required" (or "RequiresNew").
I am not sure what you meant by "concurrency issues"
when using MDBs.
Please could you clarify.Sure, if your BMP, as called from the MDB, blows up, you rollback the transaction. Which means the EXACT SAME message that caused the error will get redelivered, based upon your server settings: either immediately or within the delay period.
This means that while your first MDB is (potentially) still dealing with whatever problems the message caused in the BMP, a second invocation of the MDB can be starting, albeit in another transaction. The state of your BMP could be undefined in this situation - which could cause an entirely different set of problems.
Even though you program EJBs as "single-threaded," you still have to consider the likelyhood of multiple invocations accessing/changing the same "piece" of data. Yes, that's what transactions are for - but there can be programmatic holes where this kind of situation can arise. You just have to be careful about what you're doing.

Difference between a persistent messages and non persistent messages in JM

Hi
This question is with respect to persistent messages , and non persistent messages .
As per the docs it says that for persistent messages the QueueSender.send() blocks until it recivies an acknowledgement .
Here my question is what is the difference between a persistent messages , and non persistent messages
Thanks in advance .

The exact behaviour depends on the JMS provider being used. But since non-persistent messages are defined to be unreliable, the provider may indeed decide that it's not necessary for the server to acknowledge the receipt of a non-durable message from a producer.
Nigel

Durable subscriptions

I am using code similar to this:
aq.connection = topicConnectionFactory.createTopicConnection( "aquser", "aquser");
aq.session = aq.connection.createTopicSession( true,Session.CLIENT_ACKNOWLEDGE);
It works no problem when sending and receiving messages from a queue (Point to Point). It works when publishing a message to a topic, but when trying to creat a durable subscription, it throws a ora-24047 error (invalid agent name, should be type NAME and not string). I am using strings similar to the above example.
This doesn't make sense as PTP works and publishing messages work using strings as the agent name, and not the NAME object.
What could be causing a Durable Subscription to be rejected when using the agent name in string format?

That specific error goes away when there are no special characters such as underscores in the name, and everything is uppercase.

Wls7 GA bridge deletes durable subscriptions on source destination when stopped

          The bridge (with durability enabled) seems to delete its durable subscriptions
          from the source destination when it is stopped in any of the following 3 ways:
          (1) uncheck the "started" box & apply
          (2) untarget the bridge from the server
          (3) gracefully shutdown the server hosting the bridge
          ..whereas if I kill the server the bridge is on, the durable subcription on the
          source destination remains.
          For me the behaviour in (1) (2) & (3) is unwanted: I want the durable subscription
          to remain, so that when I start the bridge again it can pick up messages stored
          for it. Is there some reason you have implemented it this way? Is there a config.xml
          attribute I can set to inhibit this behaviour? Or is there a patch for it?
          In my case the bridge is running on a standalone admin server, with a local target
          destination; the source destination is on a remote wls7 managed server instance.
          I can send you config.xmls for everything but I don't want to post them here.
          We're using lots of bridges to simplify our JMS topology.
          (I'll raise a case for this too, I just wanted to log it here.)
          Regards,
          Jeremy.


It is not the intended behavior and looks like a new bug introduced in 7.0.
          I have filed an internal change request for this (CR082386).
          Thanks,
          Dongbo
          "Jeremy Watson" <[email protected]> wrote in message
          news:[email protected]...
          >
          > The bridge (with durability enabled) seems to delete its durable
          subscriptions
          > from the source destination when it is stopped in any of the following 3
          ways:
          > (1) uncheck the "started" box & apply
          > (2) untarget the bridge from the server
          > (3) gracefully shutdown the server hosting the bridge
          >
          > ..whereas if I kill the server the bridge is on, the durable subcription
          on the
          > source destination remains.
          >
          > For me the behaviour in (1) (2) & (3) is unwanted: I want the durable
          subscription
          > to remain, so that when I start the bridge again it can pick up messages
          stored
          > for it. Is there some reason you have implemented it this way? Is there
          a config.xml
          > attribute I can set to inhibit this behaviour? Or is there a patch for
          it?
          >
          > In my case the bridge is running on a standalone admin server, with a
          local target
          > destination; the source destination is on a remote wls7 managed server
          instance.
          > I can send you config.xmls for everything but I don't want to post them
          here.
          > We're using lots of bridges to simplify our JMS topology.
          >
          > (I'll raise a case for this too, I just wanted to log it here.)
          >
          > Regards,
          > Jeremy.

Having horrible service with 4GLTE I have had 3G for several weeks (I am not the only person I know having this problem), I have reset my network settings and it did not resolve the issue. I am also unable to send SMS and text messages without them eithe

Having horrible service with 4GLTE I have had 3G for several weeks (I am not the only person I know having this problem), I have reset my network settings and it did not resolve the issue. I am also unable to send SMS and text messages without them either failing or not sending at all. Is there an outage in the Cleveland, Ohio area (zip codes 44129, 44134, 44137) or anything else I can do to resolve this issue?

Not that I'm a Verizon employee, but I have experience in the field. An LTE tower will only extend up to, on a perfect day, with no elevation, 6-7 miles. On a typical day, you will be lucky at four (4) miles. The three ZIP codes you've given are all within about a 12 mile radius. That would mean that 2-3 towers are currently down at the same time, and Verizon would know about it within the hour. Being it's Cleveland, I'm sure they would receive numerous calls regarding an outage of that size.
My point is that if you're having issues in all three ZIP codes, chances are it's a phone issue. If you're handset is simply not receiving LTE, but still receiving 3G, that would signify a SIM card issue. You need to get your SIM card replaced.

How can I delete a message without opening an adjacent one?

Before Yosemite you could delete a message from Mail.app without opening an adjacent message by holding option and clicking the garbage can.
However, in Yosemite, there doesn't seem to be a way to delete a message without opening (and setting the message's status to "read") an adjacent message.
I often don't have time to read all the messages in my Inbox so I'll quickly read some important ones and I'll leave the others as "unread" to get back to later in the day. Yosemite Mail doesn't seem to support this workflow anymore…
Anyone know a workaround; short of manually setting a messages status back to "unread"?

Ok, I'm answering my own question. I made up a fake user name to get into my Palm Desktop and deleted profiles. Then I went in with real user name. All of my calendar entries were gone, but fortunately within the last month I had HotSynced and was able to HotSync again to get it back from my handheld. I think I need a blackberry. This stuff happens way too often.
Post relates to: Palm m505

Can I print a Mail message without multiple recipient names?

Is there a way to print a Mail message without having also to print the dozens of recipients, where that's the case? I can't see an obvious way, but I'm sure I used to be able to do this. I'd be grateful if anyone knows how.

HI,
Go here and download this utility. Print Selection 1.1
"You can select text and graphics in any cocoa application (safari, mail.app, etc.), go to the services menu and go to "Print Selection" and the selected stuff will be printed."
Carolyn

Persisted messages without durable subscriptions

Similar Messages

Maybe you are looking for