Try PubSub+
If you haven't already, check out our new Developer Portal! You'll find useful information about Solace PubSub+ as well as handy resources to get you started.

Challenges while attempting to use Solace standard Version

NagaNaga Member Posts: 32
edited November 15 in PubSub+ Software

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

  • swenhelgeswenhelge Member, Employee Posts: 4

    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

  • NagaNaga Member Posts: 32

    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 ?

  • AaronAaron Member, Moderator, Employee Posts: 10 mod

    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?

  • mhilmenmhilmen Member, Employee Posts: 7

    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.

  • mhilmenmhilmen Member, Employee Posts: 7
  • NagaNaga Member Posts: 32

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

  • mhilmenmhilmen Member, Employee Posts: 7

    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/

  • NagaNaga Member Posts: 32

    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?

  • amackenzieamackenzie Member, Employee Posts: 9

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

  • mhilmenmhilmen Member, Employee Posts: 7

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

  • NagaNaga Member Posts: 32

    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 .

Sign In or Register to comment.