Is it possible to know whether any Eip has been used in my context, a unique id or something like that..!
When exchange is copied , for each copies Event is notified, is there any possibility to restrict it to notify once..
Ref: Used and tested with the Apache Camel "MultiCast" eip
Solution:
1: Eip - Multicast will be available in the CamelExchange properties... as CamelMulticastIndex.
2: Eip - WireTap, will be available in Camel MessageHistory(InOnly) pattern...
Hope it helps in solving ...
You can assign id's to any processor or endpoint in camel. Would that help ?
Related
My gateway uses the Raspi and RFM95 configuration and operates at 915 MHz. I am using the single channel packet forwarder code by tfelkamp (https://github.com/tftelkamp/single_chan_pkt_fwd).
My gateway only the detects the first message it received and ignores the all messages afterwards. It is still connected to the TTN server but does not receive any more messages.
Can anyone explain what might be the cause of this? Might it because the RFM95 sleeping or the code no longer forwarding the message from the transceiver.
Thanks
I experienced a similar issue. Please note your sender is using different channels, but starts with channel(0). This is the first successful message you receive. Your single channel receiver is just able to receive channel(0). There is a work around for this issue for your sender explained here
This sounds like your transmitter sends the messages using frequency-hopping, while your receiver does not handle it correctly (or the other way around).
Definition of frequency-hopping found in chapter 4.1.1.8 of Semtech's SX1272 datasheet:
Frequency hopping spread spectrum (FHSS) is typically employed when
the duration of a single packet could exceed regulatory requirements
relating to the maximum permissible channel dwell time. This is most
notably the case in US operation where the 902 to 928 MHz ISM band
which makes provision for frequency hopping operation. [...]
If you're using the LMIC-Arduino library for your node then yes, by default it is transmitting in a range and the single_chan_pkt_fwd gateway is only receiving on the frequency you specify in the global_conf.json or the .cpp source (depending on your chosen library).
With the assumption that you're using the arduino-lmic library, make the changes/additions mentioned in the this TTN forum post linked by Rainer which is the same I ran into.
Also... you'll find this further down the thread: in src > lmic > lmic.c edit the following:
void LMIC_disableChannel (u1_t channel) {
if( channel < 72+MAX_XCHANNELS )
//LMIC.channelMap[channel>>4] &= ~(1<<(channel&0xF)); // comment this one
LMIC.channelMap[channel/16] &= ~(1<<(channel&0xF)); // add this one
}
Then pick a frequency on channel 0 and set that for both node and packet forwarder. Here's a table snip from this page. I went with 902300000 and it's working fine.
"freq": 902300000,
"spread_factor": 7,
I'm having following testing scenario for Spring Cloud Stream based application.
I'm having one topic for my application with two queues. BindingKey for first queue is named "cities", for the second queue is the binding key "persons".
Please howto set routing key for the Spring Cloud Stream Rabbit producer??? To distinquish where the message will be consumed?
This is my binding configuration:
spring.config.name=streaming
spring.cloud.stream.bindings.citiesChannel.destination=streamInput
spring.cloud.stream.bindings.citiesChannel.group=cities
spring.cloud.stream.rabbit.bindings.citiesChannel.consumer.durableSubscription=true
spring.cloud.stream.rabbit.bindings.citiesChannel.consumer.bindingRoutingKey=cities
spring.cloud.stream.bindings.personsChannel.destination=streamInput
spring.cloud.stream.bindings.personsChannel.group=persons
spring.cloud.stream.rabbit.bindings.personsChannel.consumer.durableSubscription=true
spring.cloud.stream.rabbit.bindings.personsChannel.consumer.bindingRoutingKey=persons
spring.cloud.stream.bindings.producingChannel.destination=streamInput
The only way howto distinguish where the message will be send(cities or persons queue) when publishing into producingChannel is through "spring.cloud.stream.bindings.producingChannel.producer.requiredGroups" property, but this is higly unusable. Because I don't wanna know anything about the queue where my message is going to land...This is AMPQ antipattern.
I want nothing simplier then just have similar functionality like through RabbitTemplate.setRoutingKey(String routingKey) method when publishing into producingChannel...:-(
Use routingKeyExpression on the producer side - see the documentation.
Since it's an expression, you'll need quotes: 'cities' or if the same producer sends to both, something like headers['whereToSendHeader'].
For those of us using yaml:
spring:
cloud:
stream:
rabbit:
bindings:
somechannel:
producer:
bindingRoutingKey: routingKey
routing-key-expression: '"routingKey"'
Source
Note the bindingRoutingKey above - this is used if you expect your queue to be bound at producer startup when using spring.cloud.stream.bindings.someChannel.producer.requiredGroups
Yes, thanks a lot.
Adding
spring.cloud.stream.rabbit.bindings.producingChannel.producer.routingKeyExpression='persons'
causes messages to land in a streaming.persons queue and
spring.cloud.stream.rabbit.bindings.producingChannel.producer.routingKeyExpression='cities'
in the streaming.cities queue. Exactly what I wanted.
Thank you. Seems that we're going to use Spring Cloud Stream in the project afterall..:-)
Another (AMQP-agnostic) way of doing this is by using the dynamic destination support, i.e. http://docs.spring.io/autorepo/docs/spring-cloud-stream-docs/Chelsea.SR2/reference/htmlsingle/#dynamicdestination
The main difference in the case of Rabbit is that you'll end up having 2 separate exchanges ('cities' and 'persons') - so it does not leverage the routing support there, but it is portable to other messaging systems such as Kafka for example.
In all Diameter implementations I saw, the messages originating from the server is always sent towards the DNS resolved IP address of whats in the Destination-Host AVP. But, in commercial servers, we see an option to configure a DRA or a DEA which takes in all the messages and routes them.
Thus, when it comes to the mobicents diameter stack, this approach is sometimes hard to do. I can anyway re-configure the hosts file so that the message ends up in a DRA/DEA, yet, its a pain. I see no option to send these messages to a central diameter agent which will take care of all the dirty work for me.
The next issue is, if I plan to create such a DRA/DEA, the stack does not accept messages to a different host. Where, the message's Destination-Host parameter might contain a different hostname than ours. (which would be the ultimate destination it needs to go)
Is there a hack to achieve this without meddling with the internals of the jdiameter code and RA code?
If you change jdiameter's config to something like this:
<Network>
<Peers>
<Peer name="aaa://127.0.0.1:21812" attempt_connect="false" rating="1" />
<Peer name="aaa://CUSTOM_HOST:4545" attempt_connect="false" rating="1" />
</Peers>
<Realms>
<Realm name="custom.realm" peers="CUSTOM_HOST" local_action="LOCAL" dynamic="false" exp_time="1">
<ApplicationID>
...
</ApplicationID>
</Realm>
</Realms>
</Network>
In your sbb, then you'll need to create a client session providing your custom realm using this method:
DiameterCCAResourceAdaptor.CreditControlProviderImpl.createClientSession(DiameterIdentity destinationHost, DiameterIdentity destinationRealm)
Example:
ccaRaSbb.createClientSession(null, "custom.realm")
where ccaRaSbb is a CreditControlProvider instance (resource adaptor interface)
finally, when creating your CCR, the method CreditControlClientSession.createCreditControlRequest() will use the session' realm to find an available peer previously configured.
Let me know if this makes sense to you
Posting the method I used to solve this problem.
As it turns out its not possible out of the box to send a diameter message towards a peer which is not configured in the stack's jdiameter-config.xml file.
For me, the option to alter the stack in this case was also not feasible. So I devised a workaround for the problem by co-operating with the DRA we have. (most DRA's should be able to handle this method)
I added two custom AVPs to the outgoing request, namely Ultimate-Destination-Host and Ultimate-Destination-Realm.
In the DRA, I asked the admin to delete my Destination-Host and Destination-Realm AVPs and replace them with the ones created in step 1.
Now, whenever I send a packet destined to other diameter peers outside the configured peer, I target them towards the DRA and set these 'Ultimate' destination AVPs.
Ours is an Oracle DSR which is capable of doing this AVP manipulation. Most commercial ones should be able to handle it. Hope someone who wanted an answer for this question found this useful.
I need to strip the rport parameter from the Via field of SIP messages being generated by Yate (for compatibility with a broken peer). Can I use the scripting capabilities of Yate to do this? How do I intercept and modify outgoing SIP messages?
I discovered, by reading the code, that Yate already supports this feature. In accfile.conf, in the section defining the sip server to register to, place the following line:
xsip_flags=1
This prevents the rport parameter from being placed in SIP messages. This may break routing if you are behind a NAT, so beware.
An example config would therefore be:
[sip_service]
enabled=yes
protocol=sip
description=sip_service
username=user
domain=somewhere.com
authname=auth
password=secret
server=somewhere.com
xsip_flags=1
I'm using Activem MQ 5.3.1
My configuration is good for classical async messaging
I try to use a QueueRequestor
The message is effectively sended, recieved.
But when it's time to answer on the temp queue i've got this exception raised
javax.jms.InvalidDestinationException: Cannot publish to a deleted Destination: temp-queue://ID:......
the destination doesn't exist
I'm using the default conf for activemq
Any idea??
I just find my answer
the implementation of queuerequestor is made for send and recieve on the same jmsSession.
That's why the reciever of the requestor never seen any message, and why the temp destination could'n be use topublish message
My solution is to create a requestor with two session.
The actuall implmentation will be very similar to the one on the blog post above