so I have been following this tutorial: http://www.rabbitmq.com/tutorials/tutorial-six-java.html, but I cant get it to work with a direct exchange.
Can someone help me out please by modifying the code so that it works with a direct exchange.
My objective: the user can chose which machine to send to, When they choose i want to bind to that machine and just send it to that machine. But it doesn't seem to be working when i change the queue declare to exchange declare. Any help would be greatly appriciated!!!
Thanks
In RabbitMQ you publish messages to exchanges, so the code you are seeing in the tutorial: channel.basicPublish("", "rpc_queue", props, message.getBytes());, means: send a message to the exchange "", using routing key "rpc_queue". That's the default or anon exchange discussed in tutorial one.
So if you want to send a message to a direct exchange, just change the empty exchange name for your exchange name.
Now, why do you want to do it that way? Why can't you instead of declaring an "rpc_queue", you declare a queue per machine, and address them by their names, in basicPublish?
Related
I'm newbie in Apache Camel, so please forgive me for the stupid question.
I am browsing examples of sending messages using multicast and I don't understand it.
I know that (in the network layer) multicast source sends datagram to specified address from range 224.0.0.0 to 239.255.255.255, to subscribers, but multicast source "does not know" how many subscribers are, only one datagram is sent for anyone of subscribers .
I do not understand either the example from the documentation (https://camel.apache.org/components/latest/eips/multicast-eip.html#_multicast_example) or from here (https://www.javarticles.com/2015/05/apache-camel-multicast-examples.html).
Why (if I understood correctly) the subscribers of the message are explicitly specified ("direct: a", "direct: b", "direct: c")?
After all, in one moment there may be 3 of them, in another time 10 of them, and so on. I don't think I need to change the code and define e.g. "direct:10", am I right?
Does the Apache Camel multicast mean something different than the one from the network layer?
Yes its not the same. Multicast EIP is a way of sending a message to N recipients at the same time (where the number of recipient is fixed/known ahead of time).
yes, you correctly understand that there is difference between network layer multicast and apache camel multicast.
The use case for camel multicast is when you want to send same message to the multiple endpoints. So in example from docs:
from("direct:a").multicast().to("direct:x", "direct:y", "direct:z");
The same message from "direct:a" will be send to all three endpoints. And the number of "destination" endpoints is defined for each route and could be different for different routes.
Note that in case of:
from("direct:a").to("direct:x").to("direct:y")
You are chaining processing of the messages. The result from the "direct:a" will be send to "direct:x" and the result from "direct:x" will be send to "direct:y", so "direct:y" could get different message as "direct:x".
Imagine there is chatting software. A java microservice listens to agents chatting with customers. The microservice dumps some pertinent data items in an SQS queue. A java bot reads from the queue, formats some things into the appropriate json and fires this off to a RESTful endpoint outside the network. Alternatively, in simulation of that bot, I can post manually properly formatted json into postman. At the last line of appcode before it is sent off in an httpRequestEntity to get a synchronous response before asynchronous processing it can be seen that the json message is properly formed. This is seen in logging and traffic sniffing. The same is true if using the postman test harness method. Some seconds later the package that got sent out of the network arrives at where it was sent.
WITH AN EXTRA JSON ELEMENT!
That reads as if it is metadata from the chatting software!
But remember this happens if the message originates in the chatting software or if I am using the fake cut in line method of mocking the message starting at a later point in the sequence.
I am so stumped. Every step of the way in every way I know to monitor data along its way the package looks right. Then at some point it doesn't. I don't want to bring this up with the people at the other end, receiving the message. Because it sounds like something that couldn't possible happen.
Please any comments even long shots would be much appreciated. I will watch this thread and respond to any questions it generates. Thank you so much.
We are developing a mail client written in Java. It has same functionalities like Outlook or Thunderbird, etc. It communicates with the mail server directly. Additionally, our business rules demand that we store all messages in our database and messages should be kept synchronised always. I know that is not very suitable for IMAP, but we must keep everything in our database.
Question arises, how to track an IMAP message moved from folder A to folder B? How can we get informed about that? If you remove a message from A, it is deleted from A and it created newly in B, as a result: The UID value of the message is changed. Can we rely on the MessageID found in the headers? I checked some mails servers and see that the message id in the headers remain unchanged. But i have read somewhere, that the messageids can be empty depending on the mail server.
Are the MessageID in headers always set, can be cases or mailservers that they leave it blank?
Are the MessageID value in headers unique in an IMAP folder?
Is it possible that it gets changed when message is moved or folders UIDVALIDITY changed?
What about setting a custom header during fetch? When I add a non-standart header name value pair, will it be kept on the mail server or is it possible that non-standart mail heraders will be deleted by mail server? Is it a bad idea applying a non-standart header value?
IMAPMessage m;
m.setHeader("myHeader", "myValue");
There were some suggestions in stackoverflow, it is said to generate a hash including messageId and other parameters such as sender, subject etc, is it a safe approach? We can get conflicts if there is no unique MessageID is provided or no MessageID is provided.
There are three things you can do.
First, message-id. You can rely on the message-id being present and unique these days if your mode of failure is good enough. In your case, if the message-id is not there and a message is moved, is the failure just that you waste space in the database and/or download the message twice? The wasted space will be small these days.
Second, x-gm-msgid. That's a gmail-specific feature, a 63-bit number that never changes. If two messages have the same x-gm-msgid, they are the same.
Third, the COPYUID response code tells you about moves, but only applies when you do the moving, not when someone else does.
Put together, these should give you a fairly good understanding of how the user's mailboxes change.
I have a chat program implemented in Java. The client can send lots of different types of information to the server (i.e, Joins the server and sends username, password; requests a private chat with another user on the server, disconnects from the server, etc).
I'm looking for the correct way to have the server/client differentiate between 'text' messages that are just meant to be chat text messages sent from one client to the others, and 'command' messages (disconnect, request private chat, request file transfer, etc) that are meant for the server or the client.
I see two options:
Use serialized objects, and determine what they are on the receiving end by doing an 'instanceof'
Send the data as a byte array, reserving the first N bytes of the array to specify the 'type' of the incoming data.
What is the 'correct' way to do this? How to real protocols (oscar, irc) handle this situation?
I've googled around on this topic and only found examples/discussions centering on simple java chat applications. None that go into detail about protocol design (which I ultimately intend to practice).
Thanks to any help...
Second approach is much better, because serialization is a complex mechanism, that can be easily used in a wrong way (for example you may bind yourself to internal content of a concrete serialized class). Plus your protocol will be bound to JVM mechanism.
Using some "protocol header" for message differentiation is a common way in network protocols (FTP, HTTP, etc). It is even better when it is in a text form (people will be able to read it).
You typically have a little message header identifying the type of content in all messages, including standard text/chat messages.
Either of your two suggestions are fine. (In your second approach, you probably want to reserve some bytes for the length of the array as well.)
I'm writing an application server that will receive SIP and DNS messages from the network.
When I receive a message from the network, I understand from the documentation that at first, I get a ChannelBuffer. I would like to determine which kind of message has been received (SIP or DNS) and to decode it.
To determine the message type, I can dedicate port to each type of message, but I would be interested to know if there exist another solution for that. My question is more about how to decode the ChannelBuffer.
Is there a ChannelHandler provided by Netty to decode SIP or DNS messages? If not, what would be the right place in the type hierarchy to write my custom ChannelHandler?
To illustrate my question, let's take as example the HttpRequestDecoder, the hierarchy is:
java.lang.Object
org.jboss.netty.channel.SimpleChannelUpstreamHandler
org.jboss.netty.handler.codec.frame.FrameDecoder
org.jboss.netty.handler.codec.replay.ReplayingDecoder<HttpMessageDecoder.State>
org.jboss.netty.handler.codec.http.HttpMessageDecoder
org.jboss.netty.handler.codec.http.HttpRequestDecoder
Also, do I need to use two different ChannelHandler for decoding and encoding, or is there a possibility to use a single ChannelHandler for both?
Thanks
If you really have a requirement for port unification (an example here), i.e. receiving different protocols on the same port, then you would have to detect the protocol in a handler and take appropriate actions. Could be as simple as inserting different handlers in the pipe line.
However, I find it very improbable that SIP and DNS would share the same port, hence no need to complicate matters.
I haven't seen a SIP decoder/encoder for Netty, but depending on what you want to do with the message, the HTTP decoder is a a very good starting point (and could be made simpler since chunking is not supported in SIP).
I would strongly recommend not to try to combine DNS and SIP decoding in one handler (or any other combination for that matter). Keep the handlers as simple and coherent as possible. Combine handlers instead, if needed.