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.

Similar Messages

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

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

  • Durable subscriptions and windows clients

    Hi,
    I think I have found a potential problem.
    Scenario
    MQ: 3.x or 4.x
    Clients: windows OS with Durable Subscriptions
    Destinations: Topic
    Problem:
    Disconnect a windows client with a durable subscription (for example, pulling the network cable)
    Try to reconnect, and you will get "Client ID already in use". Under unix, this happens only for a few secs and that's fine. Under Windows, you won't be able to reconnect for almost 10 minutes. That means that a windows client can't easily reconnect if it uses a durable subscription, and has to wait the server killing its socket.
    The problem seems that the server socket stays ESTABLISHED (just do a netstat -an | grep -i ESTABLISHED on the server) for a longer time when the client is windows. So that is a windows socket problem (I just tried with a Simpel TCP Server and that's the same), but I think a JMS server should circumvent it
    Possible solutions:
    - MQ client overriding the connection if a client id is already in use AND the connection comes from the same IP. I think that should be the default!
    - a configurable heartbeat between client and server
    - Something like "imqcmd deactivate dur" could do the job. I haven't found a way to manually DISACTIVATE the connect, but only to destroy it (imqcmd destroy dur), which obviously isn't a viable option (possible msg loss)
    - Java API to do the same thing
    ciao,
    uL

    I think that the problem may be with the TTL on the sockets. Basically as far as I know unless there is a traffic on the connection there is no way to detect that the other end of a socket connection is gone. You may try enabling ping on the connection this may speed things up.
    Tom

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

  • 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

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

  • HT204153 How do I use a satellite subscription with my Apple TV?

    llooking to use a satellite subscription with my Apple TV how do I do that?

    Hello gigimaid,
    If your satellite service connects to a modem or router, you should be able to use either Wi-Fi or ethernet to connect your Apple TV to the internet. This resource should help:
    Switch between wired and wireless networks on your Apple TV
    Disconnect the Ethernet cable from the Apple TV.
    Navigate to Settings > General > Network to join a Wi-Fi network.
    A list of available wireless networks will appear. Using the up and down buttons on your remote, navigate to the network you wish to join and select it.
    If your wireless network requires a password, a keyboard will appear, allowing you to enter the password using your remote.
    If the network you wish to join is hidden, click Other. Then enter the network name using the onscreen keyboard and the remote. Enter the password if necessary.
    After Apple TV has joined the network, a Connection Succeeded screen should appear. Click Done. The screen now should display the wireless network information, including network name, IP address, Wi-Fi address, and signal strength.
    To switch back to a wired connection, connect the Ethernet cable. Apple TV will switch to the wired connection automatically. Apple TV prioritizes a wired Ethernet connection.
    Thank you for using Apple Support Communities.
    Cheers,
    Sterling

  • Formulas, superscripts and subscripts with Pages on iPad?

    How to write formulas, superscripts and subscripts with Pages on my iPad? Do i need a third part app? If so, could anyone suggest one?
    Thank you!

    I've found a possible solution to insert equations and formulas without Latex or copy/paste images, only with Pages for iPad and without internet, using Pages tools. So, I have some examples of Pages documents. If you want to take a look them, give me your email and I'll send you an example.

  • Problem with CDN - Could not retrieve the cdn enpoints in subscription with id...

     I tried to set-up a CDN endpoint over a storage account last night and kept getting 404. suspecting that this is just time to propagate I called it a day.
    This morning when I went to look again - my CDN endpoint was not visible in the portal and instead I get the warning.
    I tried to set-up a new endpoint and that fails too, now I have two warnings -
    Could not retrieve the CDN endpoints in subscription with ID '34280cfc-814c-4d35-8836-0ec2b7ce68e7'.
    Could not retrieve the CDN endpoints in subscription with ID '440d3de7-23fd-424f-8961-a57f6f6384ed'.
    Any thoughts?
    Yossi Dahan - http://yossidahan.wordpress.com - [To help others please mark replies as answers if you found them helpful]

    Hi,
    This issue is reported at Azure Status:
    https://azure.microsoft.com/en-us/status/#history below is the detailed information, the incident has now been mitigated.
    7/30
    CDN - Multi-Region - Partial Service Interruption
    This incident has now been mitigated. From 30 July, 2014, at 06:00 to 18:28 UTC, engineers received reports of an issue in which CDN customers might experience issues while creating new CDN connections and accessing their existing content. Error messages
    indicated "Warnings occurred while loading the management data for this resource type" and "Could not retrieve the CDN endpoints in subscription with ID". Preliminary investigations indicate that this incident was caused by a misconfiguration of Network endpoint
    connecting to the service, and engineers implemented a configuration change to mitigate impact.
    Best Regards,
    Jambor
    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click
    HERE to participate the survey.

  • Ven though i have a year student subscription with creative cloud when i try to open the programmes a window comes up for free trial or to buy the product. I was clicking the free trial option but i guess thats over now so it won't allow me to access the

    Even though i have a year student subscription with creative cloud when i try to open the programmes a window comes up for free trial or to buy the product. I was clicking the free trial option but i guess thats over now so it won't allow me to access the programs. Any suggestions?

    Hi natasachara,
    Please refer to the details about the student plan below:
    Creative Cloud Help | Creative Cloud for Students and Teachers / Common Questions
    Regards,
    Sheena

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

Maybe you are looking for