[claudiobosticco]

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:

messaging.dispatcherImplementer: com.isomorphic.messaging.JMSMessageDispatcher
messaging.jms.context: _container_
messaging.jms.jndiPrefix: jms
messaging.jms.topicConnectionFactory: ConnectionFactory
messaging.jms.encoding: json

connectionFactory configuration:

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

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

... if I don't add these attributes:

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:

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

[claudiobosticco]

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.

[Isomorphic]

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

[Isomorphic]

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

[claudiobosticco]

I'm not referring to the warnings, but to the JSON encoding issue, from post #42:

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

[Isomorphic]

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

[claudiobosticco]

Hello, any news about the JSON encoding issue?

[claudiobosticco]

Hello, are there any updates about this issue?

[claudiobosticco]

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

[Isomorphic]

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?

[claudiobosticco]

Hello, may I ask for an update?

[claudiobosticco]

Still under consideration. The snag is that JSON date formats aren't standardized.

Hello, do you have some news, or an ETA?
Thanks

[claudiobosticco]

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.

Other than warnings, do you see any breakage?

No, actually the remote debug seems to work, only slowed down by the warnings.

[Isomorphic]

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?

[Isomorphic]

any update on this issue?

Still under consideration. The snag is that JSON date formats aren't standardized.