Announcement

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

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

    Leave a comment:


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

    Leave a comment:


  • Isomorphic
    replied
    May 16th now...there were some showstopper regressions in today's candidate.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • Isomorphic
    replied
    Again, is this a blocker in some way? It seems we have already found a configuration that works, but just logs some bogus warnings.

    Leave a comment:


  • claudiobosticco
    replied
    Hello, any news about the JSON encoding issue?

    Leave a comment:


  • claudiobosticco
    replied
    Hello, are there any updates about this issue?

    Leave a comment:


  • claudiobosticco
    replied
    Thanks for the update. And no, I can't say it's a blocker, at present, so the ETA is fine for me.

    Leave a comment:


  • Isomorphic
    replied
    The remoteDebug warnings issue is pretty low priority - that's on the backburner for now. The JSON encoding issue is being actively looked at though. Should have a solution in a week or two. Is this a blocker for you?

    Leave a comment:


  • claudiobosticco
    replied
    Hello, may I ask for an update?

    Leave a comment:


  • claudiobosticco
    replied
    Originally posted by Isomorphic View Post
    Still under consideration. The snag is that JSON date formats aren't standardized.
    Hello, do you have some news, or an ETA?
    Thanks

    Leave a comment:


  • claudiobosticco
    replied
    Originally posted by Isomorphic View Post
    Accurate?
    I'll try to be more clear.
    - I open a Chrome window, and I access my application with ?isc_remoteDebug=true
    - then I open a Firefox window, same machine or another gives the same result, and I access the same application (without ?isc_remoteDebug=true)
    - I open the developer console of the Firefox instance
    - I select the Chrome instance from the 'remote' select item, and I start seeing the warnings.


    Actually I've just noticed that it's also sufficient one browser instance with ?isc_remoteDebug=true, and selecting itself from its dev console.

    I'm attaching part of tomcat logs, if may be of help. Note that it's a zip file renamed in .txt.

    Originally posted by Isomorphic View Post
    Other than warnings, do you see any breakage?
    No, actually the remote debug seems to work, only slowed down by the warnings.
    Attached Files
    Last edited by claudiobosticco; 6 Dec 2017, 01:50.

    Leave a comment:


  • Isomorphic
    replied
    Re: the warnings. I'm trying to reproduce this and failing. Am I reading this correctly that you have 2 dev consoles open (same browser instance different tabs or different browsers?) and you have one other page open that you want to debug. Initially you have the first dev console target that page, then you go over to the 2nd dev console and select that same page to debug over there and you start seeing warnings. Accurate?

    Other than warnings, do you see any breakage?

    Leave a comment:


  • Isomorphic
    replied
    Originally posted by claudiobosticco View Post

    any update on this issue?
    Still under consideration. The snag is that JSON date formats aren't standardized.

    Leave a comment:

Working...
X