[jbertram]

For this static connector definition to work in domain mode, instead of just having connections to all the *other* nodes, it would have to define connections to *all* nodes (which for each node would include "self").

I don't see why you'd have to define connections to all nodes.  Just configure a connector to the other node and then use system property substitution to customize the IP address or hostname for the outbound-socket-binding on each server.

This appears to be an anti-pattern, as described in the WildFly docs thusly...

For what it's worth I believe this is from the JBoss EAP 6.x documentation which is technically different than Wildfly.

P.S. - I could probably dig up the conversation we had with your team. It was with yet another engineer. I was not directly part of that conversation. I'd also be interested to read it .

I suppose the ball is in your court on that one.

[nunnakirankumar]

Thanks Justin. With the updated configuration, we see messages are distributing across the nodes.

BUT, we see few messages in the QUEUE are missing in the clustered env (again, in the clustered env ONLY). We didnt see any ERROR/Exception in the log file.

While looking the forums, I found this link https://developer.jboss.org/thread/205384?tstart=0 (Similar to our problem).

Any clue?

Thanks.

[jbertram]

I don't think referencing an old forum thread is going to be terribly helpful in this situation.  Please give a full explanation of the use-case with special attention to:

1. What the application did.
2. What you expected to see.
3. What you actually observed.

[nunnakirankumar]

Justin,

Here is the scenario:

From a producer (an external tool), we sent 11 Messages to a Queue (named: queue/analysis).

Master Node Processed, 6 Messages and are MF1, MF3, MF5, MF7, MF9, MF11 (Note: Sample Ids for reference)

Slave Node Processed, 5 Messages and are MF2, MF4, MF6, MF8, MF10.

So messages are distributed across the both nodes and clearly see that all the messages are processed successfully. (again NO issues here, as we can clearly see processed messages in DB)

Now, once messages are processed, application will send another message to a different Queue for each message (MF1 to MF11) that received/processed (named: queue/response). And here is the problem, application is sending all the 11 messages successfully to above queue (queue/response) (Again, NO ERROR/Exception in the log). But the Listener that is reading on this queue (queue/response) is receiving ONLY 6 (sometimes 5) only. Its seems few messages are getting dropped some where.

As an example here, the 6 messages that reached above listener are MF1, MF3, MF8, MF10, MF7, MF6 (a combination of messages that are processed in Master and Slave)

Note: If I shutdown all the nodes, application is behaving as expected. No missing/dropping of message anywhere. (So issue is with clustered env ONLY)

To summarize:

• What the application did.

Few messages are getting dropped (after successfully sending to Queue)

• What you expected to see.

No messages should be dropped after sending to Queue. (In the clustered env)

• What you actually observed.

In clustered env, messages are getting dropped.

Thanks in advance.

[jbertram]

Can you attach your configuration?

[nunnakirankumar]

Justin Bertram wrote:

Can you attach your configuration?

Attached the domain.xml file.

Thanks.

[jbertram]

When you refer to the "queue/response" destination I assume you mean the destination with the JNDI entry of "/queue/icp/response" since there is no destination with a JNDI entry of "queue/response."

Do you have a consumer for "/queue/icp/response" attached to all nodes of your cluster?  If not then you will not receive all the messages sent to that destination since you have not enabled message redistribution.

[swany]

Justin,

Your comment exposed a critical flaw in our configuration. We had forward-when-no-consumers set to "true" (not sure why). Our topology is a single external entity (running on the cluster "master" node) submitting claims to our cluster, and expecting responses. Since the cluster is homogenous and there are always MDBs / RAs listening on every node, the setting did not matter for inbound requests, but for replies back to that single entity, only half were making it back, because the other half (two-node test cluster) were being sent to the node where the one entity was not listening.

Fixed the setting and all seems to work just great.

Thanks.