I am making outgoing calls to a load-balanced SBC which has two nodes. Since freeswitch is reusing the same open TCP/TLS socket to the SBC for every outgoing call, the load is not getting distributed across the two nodes of the SBC. All the calls are going to the same node.
If I can force each new call to use a different TCP connection, the load will get distributed evenly. Is there any configuration that makes this possible?
I looked into relevant conf file settings, nothing looks promising.
I eventually found the answer and didn't remember I had posted the question here. The answer is not very useful though.
Freeswitch will use a new connection every time by using the "reuse-connections" field in the gateway definition under sip_profiles.
<gateway name="{{unique_gw_name}}">
<param name="username" value="test"/>
<param name="password" value="test"/>
<param name="proxy" value="{{ip_address}};transport=tcp"/>
<param name="realm" value="*"/>
<param name="register" value="false" />
<param name="reuse-connections" value="false"/>
<param name="auth-calls" value="false"/>
<param name="caller-id-in-from" value="true"/>
</gateway>
However, this will achieve very little. The SIP call will contain at least two SIP dialogs, one for INVITE and another for BYE. If different connections are used, the INVITE might go to one SBC and the BYE may go to another SBC. So the whole thing will fail. This is not the right way to achieve load balancing.
Related
We're currently having problems with our ActiveMQ 5.16.1 which suddenly starts piling up messages without any apparent reason. The following image shows the ActiveMQ QueueSize:
The ActiveMQ is used as JMS message broker without any other components for e.g. high availability or load balancing. Several producers (in total and worst case around 20) produce small/simple JSON messages which are send to the broker and consumed by a JAVA-based microservice. The microservice processes the message and saves the data to an Oracle database. Average processing time for one request is about 30ms. From those 20 producers only some are active at the same time which might vary between 2 and 10 producers. Each producer sends a message every 3 secondes resulting in 20 messages/min per producer. E.g.: having 10 producers the broker will get 200 messages/min or 30 messages/sec. Preserving the order is crucital thus I'm working with JMSXGroupIds which works good so far. Messages are send via MQTT and routed (via Camel) to an JMS queue:
<route id="handleData">
<from uri="activemq://topic:some.topic.here?clientId=uniqueClientId" />
<setHeader headerName="tName">
<constant>ABC123</constant>
</setHeader>
<setHeader headerName="JMSXGroupId">
<jsonpath>$.producerId</jsonpath>
</setHeader>
<to uri="activemq://queue:myQueue" />
</route>
But for any reason the messages get stuck after some time and I can't find any significant hint why that happens. There is nothing in the log files nor the OS event log. I have to restart the ActiveMQ service in order to "reanimate" it. Afterwards all stuck messages will be processed and everything is working fine until the next "accident". This time it took about 10 days before the messages got stuck.
I already checked whether there might be a network or database-related issue. Even moved the ActiveMQ to a freshly new server in order to asure that nothing else is influencing the ActiveMQ processes. But I couldn't find any hints either. I watched the JVM, heap space growth, memory usage, etc. - everything unremarkable.
Does anybody has an idea what I could check additionally to find out what the problem is?
Add the advisoryForSlowConsumer destinationPolicy setting for those topics and watch the topic://ActiveMQ.Advisory.. for any enqueue counts that would indicate slow consumer occurred.
Your Camel route is almost identical to what a VirtualTopic does. You'll see better consistency with server-side routing in these types of scenarios, since there is no remote process (ie. Camel route) to manage connections, sessions, etc.
Bonus: MQTT transport supports using Virtual Topics to back-end the subscriptions so you any MQTT topic consumers would automatically pull from the queue.
ref: https://activemq.apache.org/virtual-destinations
I'm working on this problem a lot of time now and can't seem to find any final solution to it.
I have a message producer that should work as a broadcaster, posting messages on two different topics. The publisher's posting process follows the flow :
Creating connection to the factory and starting it.
Creating session
Creating Message Producer by using the session and a given topic Name
Sending n* of messages
Waiting n seconds
Closing producer,session,connection
Then i have 3 consumers subscribed to those topics by using the following configuration (each consumer has it's own clientId and durableSubscriptionName):
<route id="consumerOneRoute">
<from uri="activemq:topic:topicName?clientId=consumerOneId&durableSubscriptionName=ConsumerOneName" />
<bean ref="consumerBean" method="processMessage" />
</route>
The fact is that my consumers don't always receive the messages, at least not all of them. Sometimes two of the consumers get all the messages and the 3rd one don't get any, sometimes random consumer receive random number of messages and so on...
One more fact that i noticed is that if i stop the broker and start it again, the consumers will receive the missing messages, and i really can't understand why won't that happen during the 1st lifetime of the broker.
Would anyone be so kind and try to aid me?
Thanks,
George.
P.S : I was thinking about using virtual topics though since my main purpose is to have a broadcasting producer that will allow other consumers to attach in the future i don't want to have the need of modifyin' the producer everytime by adding another virtual branch to the main topic.
I had similar issue, 1 producer sends messages via topic to many consumers, not all of them receives messages. Problem was in consumer's timeout, I manually created timeout and it was shorter then ActiveMQ could deliver last messages. Extending timeout - helped.
Take a look at Prefetch Policy. If you set it to 1 then it may fix this one for you.
...&consumer.prefetchSize=1
The only solution that worked was switching from Topics with durable consumers to Virtual Topics.
your consumers must be connected to broker when producer is sending message.
The Camel documentation says
"The FTP consumer (with the same endpoint) does not support concurrency (the backing FTP client is not thread safe). You can use multiple FTP consumers to poll from different endpoints. It is only a single endpoint that does not support concurrent consumers."
http://camel.apache.org/ftp2.html.
Issues is with a route configuration that has multiple consumer endpoints on the same ftp server, with the same accounts, but different path:
Pseudo code:
<from uri="ftp:localhost/input01?username=test&password=test"/>
<from uri="ftp:localhost/input02?username=test&password=test"/>
In view of above mentioned limitation - does this count as two endpoints or as one ? In other words, can we expect the two consumers to be thread-safe ?
Also is this possible to consume two paths in same consumer as follow?
<from uri="ftp:localhost/input01,/input4?username=test&password=test"/>
<from uri="ftp:localhost/input02,/input3?username=test&password=test"/>
You can use multiple (1 per route) while still being thread-safe, as each use its own FTP connection (possibly with different credentials).
About you second question, ftp:localhost/input01,/input4?... is not an acceptable URI.
Please see the documentation, only one directory name can be provided, but it can have nested folder.
ftp://[username#]hostname[:port]/directoryname[?options]
Where directoryname represents the underlying directory. Can contain nested folders.
If you have control on the FTP structure I would suggest to regroup the folder under a common parent in order to poll on it.
Otherwise you can use 4 consumers, one per folder (01 to 4) and route files from 01-02 to a given route and 3-4 to another route.
I'm designing a simple business process using Tibco Designer. Basically, it's like
Receive xml data via JMS --> Extract certain data from xml and modify it --> send back the modified xml
So my question is, which activity from Palettes should I choose to implement the manual task ?
For example:
original.xml
<xml>
<sender>Jason</sender>
<message>I am hungry</message>
</xml>
modified.xml
<xml>
<sender>Jason</sender>
<message>I am hungry</message>
<modifiedMessage>I am so hungry!!!!!<modifiedMessage>
</xml>
So I want to extract from original.xml and maybe show it on screen, and then ask for user's input for modified message. After user put in message, we will add it as another element and send the modified.xml to other destination.
Well, TIBCO BusinessWorks (as well as TIBCO Designer which is just a modeler for business processes) is not made for that kind of using - human interaction between process steps (activities). You probably need some kind of BPM tool with rich GUI forms and all other fancy stuffs.
With TIBCO BW you can receive JMS message using "JMS Queue Receiver" but you have to know XML schema for that JMS message. After that, you can 'extract' some data from it with for e.g. "Mapper" activity and after that you can send message back to the same queue with "Reply to JMS Message" activity.
I want to set up a JMS sender and a JMS receiver in different instances. I am trying to set up the replyTo queue, but once I set up OUT_ONLY=true, the replyTo header is not set up in the JMS message.
Is there any way to configure the replyTo queue, per sequence, without waiting for the reply?
Thanks in advance.
Ramon
In Case anybody is still interested (and since the wso2 folk seem to never be around to provide any support here) I manage to eventually stumble on an answer (I have raised a simialr question) in an old obscure jira defect where it happens to be mentioned.
the sequence should set a couple of properties like so prior to the send mediator.
<property action="set" name="OUT_ONLY" scope="default"
type="STRING" value="true"/>
<property action="set" name="JMSReplyTo"
scope="transport" type="STRING" value="yourqueuename"/>
yourqueuename will be prefixed by queue:// by synapse so dont worry with any of that, just the name is fine (and if it doesnt exist, the loveliness that is jms will create it for you). Also note the scope of the property is "transport".
hope that was useful to somebody else, it sure took me the best part of a day to stumble on the answer.
thanks Paul