Uploaded image for project: 'RichFaces'
  1. RichFaces
  2. RF-13929

a4j:push does not work with subtopics and JMS

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 4.5.0.Final, 4.5.1
    • Fix Version/s: 4.5.2
    • Component/s: component-push/poll
    • Labels:
    • Environment:

      Mojarra 2.2.8, Tomcat 7.0.54, Java 1.7.0_67, ActiveMQ 5.10.0

      Description

      Using a4j:push with JMS support works fine when using basic topic names only. But using a4j:push components, which are registered to a specific subtopic name, never receive data.

      For example I have a JMS topic "mytopic".

      The topic is initialized on application start, using a JSF SystemEventListener:

      public void processEvent(SystemEvent event) throws AbortProcessingException {
          TopicsContext topicsContext = TopicsContext.lookup();
          topicsContext.getOrCreateTopic(new TopicKey("mytopic"));
      }
      

      For demonstration purposes there are three different pages with a4j:push components registered to different topic addresses:

      <!-- a4j:push on page 1 registered to subtopic1 -->
      <a4j:push address="subtopic1@mytopic" ondataavailable="alert('subtopic1')"/>
      
      <!-- a4j:push on page 2 registered to subtopic2 -->
      <a4j:push address="subtopic2@mytopic" ondataavailable="alert('subtopic2')"/>
      
      <!-- a4j:push on page 3 registered to no subtopic -->
      <a4j:push address="mytopic" ondataavailable="alert('no subtopic')"/>
      

      JMS messages with subtopic names are triggered using the subtopic-workaround described here: https://developer.jboss.org/wiki/CreatingSubtopicWithJMSPush

      For example:

      ObjectMessage message = jmsSession.createObjectMessage(true);
      message.setStringProperty("rf_push_subtopic", "subtopic1");
      jmsPublisher.publish(message);
      

      For any JMS message (with or without subtopic) page 1 and page 2, which are registered to subtopics, never receive data (this is the bug ).

      Page 3 always receives data (as expected).

      After debugging, I think the subtopic information gets lost in JMSTopicsContextImpl$JMSConsumerContext lines 206-217. There "getOrCreateTopic(topicKey)" is called with the topicKey that correctly contains the subtopic name. The returned topic "pushTopic" is the one that was created on application start. It contains an internal TopicKey without subtopic name. When calling "pushTopic.publish(messageData)" in line 213 the pushTopic has no information about the subtopic any more. Internally TopicImpl holds a collection of connected sessions (which is filled correctly) but it cannot get the correct PublishingContext (see TopicImpl line 63) because it uses its internal key (without subtopic name) to access the map.

      I tried a patched version where the subtopic name is propagated into the TopicImpl.publish(...) method and getPublishingContext(...) is called with a new key that contains the subtopic name if available. Then all pages receive their data as expected.

      Modified TopicImpl:

      public void publish(Object messageData, String subtopicName) throws MessageException {
          String serializedData = getMessageDataSerializer().serialize(messageData);
          if (serializedData != null) {
              PublishingContext topicContext = getPublishingContext(getKey());
              if (topicContext != null) {
                  topicContext.addMessage(serializedData);
              }
              // optionally publish to all clients that are registered to a specific subtopic
              if (subtopicName != null && getKey().getSubtopicName() == null) {
                  topicContext = getPublishingContext(new TopicKey(getKey().getTopicName(), subtopicName));
                  if (topicContext != null) {
                      topicContext.addMessage(serializedData);
                  }
              }
          }
      }
      

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                goeldner Christoph Göldner
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: