Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    #61
    I'm not referring to the warnings, but to the JSON encoding issue, from post #42:
    Originally posted by claudiobosticco View Post
    ...
    In the messaging callback, I see that every data field is a string, ie:
    - booleans are "true" and "false" (as a string)
    - numbers (as ids or others) are also strings, so 2979574 became "2979574"
    - dates are rendered as "$$DATESTAMP$$:1511725500000"
    ...
    This is a blocker in the sense that I can't migrate to RabbitMQ until it's fixed.

    Comment


      #62
      This appears to have been overlooked - sorry about that. Resolved now - fix should appear in May 15 2018 build!

      Comment


        #63
        May 16th now...there were some showstopper regressions in today's candidate.

        Comment


          #64
          Hello, sorry for the long silence here....I'm testing with
          SmartClient Version: v11.1p_2018-09-26/Enterprise Deployment (built 2018-09-26)
          but I'm seeing a date delivered as:
          "$$DATESTAMP$$:1538119438472"

          booleans and numbers are fine.
          The warnings issue (post #53) seems also fixed.
          Last edited by claudiobosticco; 27 Sep 2018, 23:57.

          Comment


            #65
            Hello, I'll add some more context.

            I'm testing with Tomcat 8.5.23 with addition of:
            rabbitmq-jms-1.8.1.jar
            geronimo-jms_1.1_spec-1.1.1.jar
            amqp-client-4.3.0.jar
            slf4j-api-1.6.1.jar

            Settings in server.properties:
            Code:
            messaging.dispatcherImplementer: com.isomorphic.messaging.JMSMessageDispatcher
            messaging.jms.context: _container_
            messaging.jms.jndiPrefix: jms
            messaging.jms.topicConnectionFactory: ConnectionFactory
            messaging.jms.encoding: json
            connectionFactory configuration:
            Code:
            <Resource  
                                 name="jms/ConnectionFactory"
                                 type="javax.jms.ConnectionFactory"
                                 factory="com.rabbitmq.jms.admin.RMQObjectFactory"
                                 username="xyz"
                                 password="xyz"
                                 virtualHost="/"
                                 host="myHost"
                                 threadsPerConnection="2"
                                 cleanUpServerNamedQueuesForNonDurableTopicsOnSessionClose="true"
                  />
            Resources (queue) configuration:
            Code:
            <Resource
                              auth="Container"
                              name="jms/updateMappaJtaChannel"
                              type="javax.jms.Topic"
                              factory="com.rabbitmq.jms.admin.RMQObjectFactory"
                              destinationName="updateMappaJtaChannel"
                    />
            <ResourceLink global="jms/updateMappaJtaChannel" name="jms/updateMappaJtaChannel"/>
            
            <ResourceLink global="jms/ConnectionFactory" name="jms/ConnectionFactory"
                                      type="javax.jms.ConnectionFactory"/>
            With these settings, the RealtimeMessaging and the remote debug are working, but with that bug on the dates which are delivered with the internal encoding.

            But then there's another issue.

            Actually I've got the same exact behaviour without the updateMappaJtaChannel resource definition, so it is ignored.

            This is in agreement with what I wrote previously in this thread, where I said that I was trying the amqp settings in the queue configuration, otherwise, as I wrote in post #34:

            Originally posted by claudiobosticco View Post
            ... if I don't add these attributes:
            Code:
            amqp="true"
            amqpExchangeName="jms.durable.topic"
            amqpRoutingKey="updateOrdineChannel"
            amqpQueueName="updateOrdineChannel"
            it creates a new queue with a single consumer for every subscribe operation and for every re-connection (after the TTL expires).
            Now If I modify the resource definition like this:
            Code:
            <Resource   auth="Container"
                            name="jms/updateMappaJtaChannel"
                            type="javax.jms.Topic"
                            factory="com.rabbitmq.jms.admin.RMQObjectFactory"
                            destinationName="updateMappaJtaChannel"
                            amqp="true"
                            amqpExchangeName="jms.durable.topic"
                            amqpRoutingKey="updateMappaJtaChannel"
                            amqpQueueName="updateMappaJtaChannel"
                    />
            and I create the updateMappaJtaChannel channel using the RabbitMQ console, I do see that the channel shows the right number of consumers, but the consumers do not receive the messages.
            Last edited by claudiobosticco; 3 Oct 2018, 06:16.

            Comment


              #66
              Hello, any news about this issue?

              Comment


                #67
                Hello, any news?

                Is our support still active?

                Comment


                  #68
                  Hi there - really sorry for the delay - looks like the forums software notification failed in this particular case and we didn't see your updates to the post until just now.

                  The $$DATE$$ string is our on-the-wire encoding for date objects. Are you saying that when you send a Date via the channel that it's delivered as that encoded string all the way to the browser? That definitely shouldn't be happening and from a quick check of the code it looks like the logic is correct...

                  As far as the other issue: the developer console uses temporary channels and can't be made to use a specific durable topic. Are you saying that even your named channels that you use for your own messaging do not work with a durable topic?

                  Comment


                    #69
                    Originally posted by Isomorphic View Post
                    The $$DATE$$ string is our on-the-wire encoding for date objects. Are you saying that when you send a Date via the channel that it's delivered as that encoded string all the way to the browser? That definitely shouldn't be happening and from a quick check of the code it looks like the logic is correct...
                    Yes, I see dates delivered with the internal encoding.
                    In my tests I'm sending the message using the client APIs, I don't know if it may be related.

                    Originally posted by Isomorphic View Post
                    As far as the other issue: the developer console uses temporary channels and can't be made to use a specific durable topic. Are you saying that even your named channels that you use for your own messaging do not work with a durable topic?
                    Yes, without the amqp attributes it creates a new queue for every subscribe operation. With the amqp attributes, the consumer doesn't receive messages (even though it shows the right number of consumers).
                    Last edited by claudiobosticco; 20 May 2022, 05:29.

                    Comment


                      #70
                      Ok, the $$DATESTAMP$$ issue is fixed and will appear in the next stable build (should be Oct 27).

                      As far as the other issue is concerned, I can't replicate the issue with consumers not receiving messages, but what I do see is that if you omit this flag:

                      Code:
                      ​​​​​​            cleanUpServerNamedQueuesForNonDurableTopicsOnSessionClose="true"
                      ...Then temporary queues do pile up. The thing is, RMQ doesn't technically have "topics", only queues. Messages are published on an "exchange" and are then routed to queues. If you manually make a queue and point the connector at it, unless you configure routing to that queue in the RMQ console, it's essentially unused because we publish to a Topic which just ends up creating a temporary queue (which is then not cleaned up unless you specify this magic flag). Does that make sense?

                      I think all you need to do is configure routing (via the RMQ admin console) from the jms exchange to your named durable queue and then the consumer of that queue should receive the messages.

                      Comment


                        #71
                        Thanks for the explanation.
                        Now I'm testing with:
                        SmartClient Version: v11.1p_2018-10-27/Enterprise Deployment (built 2018-10-27)
                        and I've defined the routing:
                        Click image for larger version

Name:	2018-10-30 09.57.00.jpg
Views:	293
Size:	37.3 KB
ID:	255688
                        but I see this error in the server logs:
                        Code:
                        2018-10-30 09:50:30,514 DEBUG MessagingConnectionHandler Delivering data: [
                        ....[cut]
                        2018-10-30 09:50:30,517 DEBUG MessagingConnectionHandler calling cleanup() 
                        2018-10-30 09:50:30,517 DEBUG  JMSMessageDispatcher closing session 
                        2018-10-30 09:50:30,518 DEBUG RPCDMI rpc returned RPCResponse 
                        2018-10-30 09:50:30,518 ERROR JMSMessageDispatcher Unable to deliver jms message 
                        java.lang.Exception: BytesMessage encoding is not supported at this time
                            at com.isomorphic.messaging.JMSMessageDispatcher.iscMessage(JMSMessageDispatcher.java:319)
                            at com.isomorphic.messaging.JMSMessageDispatcher$1.onMessage(JMSMessageDispatcher.java:280)
                            at com.rabbitmq.jms.client.DeliveryExecutor$CallOnMessage.call(DeliveryExecutor.java:33)
                            at com.rabbitmq.jms.client.DeliveryExecutor$CallOnMessage.call(DeliveryExecutor.java:23)
                            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
                            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
                            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
                            at java.lang.Thread.run(Thread.java:745)
                        am I missing something else?

                        Comment


                          #72
                          Originally posted by Isomorphic View Post
                          Ok, the $$DATESTAMP$$ issue is fixed and will appear in the next stable build (should be Oct 27).
                          BTW, this is fixed with SmartClient Version: v11.1p_2018-10-27/Enterprise Deployment (built 2018-10-27)

                          Comment


                            #73
                            Please try out tomorrow's (Nov 9) build. The error you're seeing with BytesMesssage encoding should be resolved there...so long as you are using json message encoding (which I think you are)

                            Comment


                              #74
                              Was the BytesMessages issue you reported was resolved for you by the latest patch build?

                              Comment


                                #75
                                Originally posted by Isomorphic View Post
                                Was the BytesMessages issue you reported was resolved for you by the latest patch build?
                                Hello, sorry for the very late reply.
                                I've just tested using this build:

                                SmartClient Version: v11.1p_2019-01-21/Enterprise Deployment (built 2019-01-21)

                                and I've got a different error:

                                Code:
                                2019-02-06 16:19:01,088 ERROR JMSMessageDispatcher Unable to deliver jms message 
                                javax.jms.MessageFormatException: Not enough bytes in message body for UTF object
                                at com.rabbitmq.jms.client.message.RMQBytesMessage.readUTF(RMQBytesMessage.java:206)
                                at com.isomorphic.messaging.JMSMessageDispatcher.iscMessage(JMSMessageDispatcher.java:320)
                                at com.isomorphic.messaging.JMSMessageDispatcher$1.onMessage(JMSMessageDispatcher.java:280)
                                at com.rabbitmq.jms.client.DeliveryExecutor$CallOnMessage.call(DeliveryExecutor.java:33)
                                at com.rabbitmq.jms.client.DeliveryExecutor$CallOnMessage.call(DeliveryExecutor.java:23)
                                at java.util.concurrent.FutureTask.run(FutureTask.java:262)
                                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
                                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
                                at java.lang.Thread.run(Thread.java:745)
                                apart for the SmartClient version, everything is configured as above.

                                Please let me know if you need more details or other tests.

                                Comment

                                Working...
                                X