AQ JMS: non-durable subscriptions not cleaned up

Whenever I create a non-durable subscription I see a TSUB_... subscription in the AQ$ tables. This subscription does not disappear when the client terminates abnormally.
This can be very annoying because these queues fill up quickly and deleting a big subscription locks the queue for a substantial amount of time.
Is there something I missed - should the QMN take care of these orphaned subscriptions ?

We are having exactly the same problem...

Similar Messages

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

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.

JMS Messages keep on growing for a Topic with non-durable consumers

I have a JMS Server whose "Messages Current" keeps on growing after every message send to the topic. All the consumers are non-durable. The session is a non-transacted session with Auto Accknowledge parameter. My client does recieve the message, but it does not go down from the "Messages Current" in the WLS console. Also once the server is restarted, the messages go down to 0.
I am using 9.2 SP2 on a Solaris environment.
Any insight would be helpful

It's possible that one or more the subscribers is stalled for some reason and so is not actually receiving and processing messages. This would cause messages to accumulate. You can examine statistics for individual consumers on the console to see if this is an issue.
Also, there could be a durable subscription on the topic left over from some previous application you used with the topic. There are statistics for these as well.
Yet another possibility is that the clients are receiving the messages but are failing to acknowledge/commit them. You wrote that the sessions are "auto-acknowledge" but they could accidentally be "transacted". Check to make sure that the first parameter passed to "createSession" is true (it should be false), and that the second parameter is set to auto-acknowledge.
Finally, if you happen to be using a distributed topic, keep in mind that if one of the topic members is unavailable/crashed/down messages will accumulate on the other distributed topic members until the unavailable member is restarted (at which point they will be forwarded to the restarted member).
Tom

Non-durable subscribers persists after the end of their JMS session

Hi all,
I'm using OAQ as my JMS Provider.
I have created code for publishing and recieving messages to/from topics. Messaging works fine, but I have one problem:
All my non-durable subscribers persists after the end of their JMS session. I always perform unsubscribe operation in code and then closing session and connection.
When I subscribe to topic, there's one more line in DB table ( etc. NAME: TSUB_1_24E6DB98A2EB7712E040A8C, TYPE: 65). I have expected that subscribers will be deleted after performing unsubscribe operation, but they don't...
Can you help me with this problem? Thanks for any answer.
Best Regards,
Juraj

Have you found a solution to this yet - because I face the same problem

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

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.
          >

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

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.

Non Durable subscribers

Hi,
I am currently developing an application in java that will use Oracle 8i's (8.1.7 to be more specific) Advanced Queuing Java API. Is there any way to mimic a non-durable subscriber in Oracle 8i? Both 8i and 9i don't support non durable subscribers.
Thanks,
Jeff
null

I'm not sure what exactly you mean by non-durable subscribers. If you are mean the subscriptions should be dropped after the session is deleted - you can create unique subscriber names for every session and unsubscribe when a session is closed. You'll have to record these subscriber names somewhere persistently and in case of abnormal session termination, you'll have to drop them later

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.

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.

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.

How can i remove my credit card from app store, the none option its not there and i don't Owen nothing to apple, my last in app purchase was in clash of clans, please help!!! Because of that problem i cant update my apps! Plz help!!!!!

How can i remove my credit card from app store, the none option its not there and i don't Owen nothing to apple, my last in app purchase was in clash of clans, please help!!! Because of that problem i cant update my apps! Plz help!!!!!

You've logged into your account and viewed your purchase history and there aren't any error messages shown (e.g. 'problem with a previous purchase'), and you haven't got any purchases due (e.g. pre-orders and/or subscriptions) : Why can’t I select None when I edit my Apple ID payment information ?

How to enable iphone application for multiple iDevices associated with single user for non renewable subscription?

I am developing an ios application which has non renewable subscription.
Which algorithm would be best if the very time an authorized user purchase my application after paying charge for it , can download it for other devices assocated with him for free?
Any help would be appreciated?
    Thanks in advance
     Neeraj@iDev

Thanks! I see a potential problem--iTunes must be open on the main(?) other computer for sharing to works, according to some of the documentation. My situation is that daughter 1 grabs the main computer, access iTunes and her account. Then daughter 2 comes into room, screams upon seeing daughter 1 using the iTunes computer.
I want daughter 2 to calmly walk to computer 2, open iTunes and somehow seamlessly access her iTunes library. In that case, iTunes may be open on computer 1, but not with her library open or her id in force. It might also be the situation that computer 1 does not have iTunes even running at that time, if daughter 1 is on Facebook.
Can Home Sharing handle this situation?
Larry

AQ JMS: non-durable subscriptions not cleaned up

Similar Messages

Maybe you are looking for