Try PubSub+

Unable to connect to existing solace queue instead trying to creating a new durable queue and fails

nbommidinbommidi Member Posts: 5

Asking help from this community after coming through several articles and sites. Didn't find solution

I want to connect and use manually created queue, but it is not working. refer the below properties and error i am getting.

Any recommendations?


Spring Boot Applicaiton created using start.spring.ip with the dependencies pubsub+, solace and Web modules
Using spring cloud stream framework
Created a queue using the solace admin console

Used the following application properties

c.s.s.c.s.b.p.SolaceQueueProvisioner : Creating durable queue scst/wk/ for consumer group
c.s.jcsmp.impl.SessionModeSupport : (Client name:


address info>- Error Response (403) - Permission Not Allowed
c.s.s.c.s.b.p.SolaceQueueProvisioner : Failed to provision durable queue scst/wk/

com.solacesystems.jcsmp.JCSMPErrorResponseException: 403: Permission Not Allowed


  • marcmarc Member, Administrator, Moderator, Employee Posts: 525 admin

    Hi @nbommidi,
    Can you post your config using ``` before and after so it puts it into a code blocK? It's hard to make out how it is. I assume there are some angle brackets in there that are getting lost.

    Also if you're creating the queue and applying the subscriptions ahead of time you can set these properties to tell the binder not to. Find out more info on them in the Solace Consumer Properties docs section.

    • provisionDurableQueue = false
    • provisionSubscriptionsToDurableQueue = false
    • provisionErrorQueue = false (if you're using the error queue)
  • nbommidinbommidi Member Posts: 5

    Hi @marc
    I have used denotation to represent the values. looks like they are lost
    See below updatd config testConsumer preconfigured queue name testConsumerGroup host name vpn name user name password

    Below is the part of the error log where it is trying to create a durable queue and failing due to a permission issue with a 403 error. my org didn't allow an application to create a queue.
    c.s.s.c.s.b.p.SolaceQueueProvisioner : Creating durable queue scst/wk/ for consumer group
    c.s.jcsmp.impl.SessionModeSupport : (Client name:

  • marcmarc Member, Administrator, Moderator, Employee Posts: 525 admin
    edited June 4 #4

    Hi @nbommidi,
    Your configuration looks close to correct to me so a few things to check:
    1. What version of the cloud stream binder are you using? If using the latest you'll want to use autoBindErrorQueue instead of autoBindDmq
    2. Since you are using that feature you'll also want to add provisionErrorQueue: false
    3. If the disabling of provisioning is being properly read by the binder you should see logs that look something like this:

    Creating durable queue scst/wk/SINK/plain/TEMPS.Q for consumer group SINK
    Durable queue provisioning is disabled, scst/wk/SINK/plain/TEMPS.Q will not be provisioned nor will its configuration be validated

    Note that this worked for me using the cloud-streams-sink sample in this repo with this config:

          definition: sink 
              destination: TEMPS.Q
              #The presence of "group" tells the binder to follow the "consumer group" pattern
              group: SINK
                  #This adds a topic subscription w/ wildcards to the queue created with a name of TEMPS.Q.SINK above 
                  queueAdditionalSubscriptions: sensor/temperature/>
                  autoBindErrorQueue: true
                  provisionDurableQueue: false
                  provisionSubscriptionsToDurableQueue: false
                  provisionErrorQueue: false
  • nbommidinbommidi Member Posts: 5

    Hey @marc, I did see that disable note when I tried several options earlier. I used to get an invalid queue or permission issue. But now I did further analysis of all my properties in earlier trials as well.

    The problem was that our predefined queue didn't accept any prefix in the queue name, but the spring cloud binder configuration automatically add the prefix with all defaults and it resulted in an invalid queue.

    I tried to use all the below properties as mentioned in the documentation at

    useDestinationEncodingInQueue =false

    I have observed the group name and familiarity name is removed from the prefix, but the encoding isn't removed.

    So I did a code review of the source code and realized that there is a typo in the property. The actual property should be useDestinationEncodingInQueueName

    Now I am able to fix the invalid queue issue.

    You may have to advise your team to correct the documentation. Sorry, I didn't set it up to fix it.

  • marcmarc Member, Administrator, Moderator, Employee Posts: 525 admin

    Great find @nbommidi. I opened this PR to fix it in the docs:

    Thank you 🙏

Sign In or Register to comment.