Challenges while attempting to use Solace standard Version

Naga
Naga Member Posts: 58
edited November 2019 in PubSub+ Event Broker #1

Hi All,
I am facing below issues is solace software standard version. Help needed urgently.
1. Posting messages to Solace topic using REST API I am giving the expiry as Solace-Time-To-Live-In-ms:10800000 but when I browse the queue (using java sdkperf tool) I see that in headers it is changing to this: 10800000.
2. I am testing the error scenario where Boomi listener is bind to solace queue. The JMS listener is able to pick messages from Solace queue but at later point of time the process fails. In this case solace should try to redeliver the message to Boomi 5 times (max redelivery attempts configured as 5 on the queue) and after all the attempts are failed message should move to Dead message queue. But here messages are still on the queue and maximum unacknowledged messages count is increasing and messages are not moving to DMQ.
3. Once the same boomi listener error is fixed and re-connected to Solace , Solace is not trying to send the previous (old) messages to the same listener. The messages are just sitting on the queue even though the consumers are available on the queue . How to fix this ? or Is this a expected behavior ?
4. What is the value accepted by solace for the REST header: Solace-Timestamp ?
My Solace software (ova) is installed on Houston servers.

Tagged:

Answers

  • swenhelge
    swenhelge Member, Employee Posts: 77 Solace Employee

    Re your first point - the two numbers you provided are the same. I suspect you supply "10800000" in Solace-Time-To-Live-In-ms but you see "10800" when you browse the queue? This would be due to the time unit changing from milliseconds to seconds.
    re 4) - Is explained here https://docs.solace.com/RESTMessagingPrtl/Solace-REST-Message-Encoding.htm: Specifies the time at which the message was originally generated, as a 64-bit decimal integer giving the time in milliseconds since January 1, 1970 00:00 UTC

  • Naga
    Naga Member Posts: 58

    Re 1st point: I was sending this: 10800000 and I am seeing this : 1573122750465 on solace queue.
    Re 4: Worked..thankyou
    Can you help me on other points as well ?

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 503 admin

    I don't know the Boomi JMS receiver component, but for #2) please provide CLi output show queue <qname> message-vpn <vpnname> detail and show queue <qname> message-vpn <vpnname> messages oldest detail.

    For #3) this sounds unexpected. Is it a non-exclusive queue? Are there selectors involved?

  • mhilmen
    mhilmen Member, Employee Posts: 7 Solace Employee

    For the DMQ and Boomi Listener piece: 1) Are you using the Boomi Generic JMS Connector or the Boomi Solace JMS Connector 2) How are you publishing your messages to the Solace queue? You need to ensure that they are being published as DMQ eligible: https://docs.solace.com/Solace-JMS-API/Message-Properties.htm#jms_properties_39190069_303895.

  • mhilmen
    mhilmen Member, Employee Posts: 7 Solace Employee
  • Naga
    Naga Member Posts: 58

    Hi mhilmen, In the headers we are passing as Solace-DMQ-Eligible: true.
    I am using Boomi solace JMS connector.

  • mhilmen
    mhilmen Member, Employee Posts: 7 Solace Employee

    Naga,
    In order to get the behavior you want, to send failed messages to a DMQ after the # of retries has expired, you need to set the Transacted? checkbox to true in the Boomi Operation. Currently, the Solace branded connector does not support this operation type. It is being updated with an ETA of Q1 2020 to support a number of new capabilities, included transacted support. Please retry this scenario using the Boomi Generic JMS Connector. If you need help getting connected, this guide walks you through the steps of using the Boomi Generic JMS Connector with Solace.
    https://solace.com/blog/pubsub-event-broker-boomi-jms/

  • Naga
    Naga Member Posts: 58

    Thank you mhilmen. The issue resolved when I used Generic JMS connector but when I selected server type as solace it is throwing below error:
    Error initializing server.; Caused by: Unable to connect to JMS server (process: b61c9e63-f4ca-4dc5-b1cf-9ef6b4f9f5d5); Caused by: Transacted sessions or XA sessions are not supported with direct transport (from Wed Nov 13 10:32:45 UTC 2019).
    I have only one connection factory under my VPN. When I select server type as Solace , Boomi does not have property to give connection factory name explicitly link we have for Generic JMS . Then Boomi should use the only connection factory available in the VPN. But I think Boomi is using some other JNDI connection factory properties where direct transport is enabled.

    Is there a way to resolve this issue or this how Boomi JMS connector is designed for server type as solace?

  • amackenzie
    amackenzie Member, Employee Posts: 259 Solace Employee

    @Naga you can go to the Connection Factory settings in the VPN JNDI settings in Web Manager and unselect Direct Transport for Non-persistent Messages. This is what the error message is complaining about.

  • mhilmen
    mhilmen Member, Employee Posts: 7 Solace Employee

    @Naga. Have you been able to confirm amackenzie's recommendation? I would also expect that type of error if you attempted to use the Solace branded JMS connector with the Transacted flag set.

  • Naga
    Naga Member Posts: 58

    HI,
    I am using Generic JNDI instead of solace as my requirement is to move messages to DMQ after all the redelivery attempts are exceeded. Else I will have to restart the listener which is not a feasible option. Thanks for the help .

  • sjaak
    sjaak Member Posts: 103 ✭✭✭

    I have a similar issue. I want to implement the following use case:

    • durable = true (topic)
    • transacted= true
    • 5 automatic retries
    • Send the failed message to a dead letter queue
      I had a few chats with @mhilmen about integrating Boomi and Solace using JMS. I know that the branded Solace connector does not support the JMS Transacted flag currently. I have tried JNDI today. Unfortunately, I get the same error message: "Unable to send JMS message; Caused by: Transacted sessions or XA sessions are not supported with direct transport" as soon as you enable the transacted flag. This thread suggested JNDI and transacted should work, however.
  • Naga
    Naga Member Posts: 58

    If you use server type as Generic JNDI in Boomi and the connection factory property: Direct Transport for Non-persistent Messages is disabled you wont be seeing that error. Please check.