[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]

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

[Isomorphic]

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

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

[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, any news about this issue?

[claudiobosticco]

Hello, any news?

Is our support still active?

[Isomorphic]

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?

[claudiobosticco]

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.

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

[Isomorphic]

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:

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

[claudiobosticco]

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:

but I see this error in the server logs:

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?

[claudiobosticco]

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)

[Isomorphic]

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)

[Isomorphic]

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

[claudiobosticco]

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:

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.