could redis different language client can mixed use? - serialization

as we know apache thrift rpc framework can use different language client store and access,for an instance,
use python client set "1"
use ruby client get "1"
they get the same value
so my question is redis support this feature?

Yes.
Redis uses a very simple protocol which is independent to language. You can use libraries from different languages and they can work together :)

Related

ActiveMQ topic send automatically

I have some subscribers that they are listening to "mytopic"...I send message to them by browser UI just like attached image
but now I want to do this work in code environment
what should I do and whats that code and methods?
-----> attached image
Thanks
You should have mentioned what programming language you want to use. Every language may offer a different API and specification.
In case of using Java, you can simply program according to the JMS specification
https://docs.oracle.com/javaee/7/api/javax/jms/package-summary.html
Also, the Apache ActiveMQ installation comes with a few examples that you can use as a reference. E.g. see
examples/openwire/swissarmy/src/TopicPublisher.java
You should have a look at ActiveMQ Protocols - for example you can use the ActiveMQ REST API to POST messages to the topic or use JMS.
Then you can look at how to use these from a "client" (presumably your central server) perspective.
For REST from Java (say) you could look at this article

C++ application as Gemfire client?

I am aware that a Java client can register as a client in a client-server model and register the Regions it is interested in. Also, when the data changes on the server, the data will automatically be sent to the client.
Is it possible to have this with a C++ client and a Java server?
Regards,
Yash
Definitely. Gemfire has a C++ client that supports pretty much everything the java client supports, including getting updates pushed to the client. Check out the documentation here:
http://gemfire.docs.pivotal.io/docs-gemfire/gemfire_nativeclient/about_native_client_users_guide.html

How does Apache thrift fits with Apache hive?

Why do Apache Hive needs Apache Thrift? On the Thrift's site it says that it can compile in multiple languages, but I can't understand where does it fits and why do Hive need it.
Thanks
Cited from safaribooksonline:
Chapter 16. Hive Thrift Service
Hive has an optional component known as HiveServer or HiveThrift that
allows access to Hive over a single port. Thrift is a software
framework for scalable cross-language services development. See
http://thrift.apache.org/ for more details. Thrift allows clients
using languages including Java, C++, Ruby, and many others, to
programmatically access Hive remotely.
The CLI is the most common way to access Hive. However, the design of
the CLI can make it difficult to use programmatically. The CLI is a
fat client; it requires a local copy of all the Hive components and
configuration as well as a copy of a Hadoop client and its
configuration. Additionally, it works as an HDFS client, a MapReduce
client, and a JDBC client (to access the metastore). Even with the
proper client installation, having all of the correct network access
can be difficult, especially across subnets or datacenters.
Couldn't have said it better. Emphasis mine.
https://cwiki.apache.org/confluence/display/Hive/HiveServer
HiveServer is an optional service that allows a remote client to submit requests to Hive, using a variety of programming languages, and retrieve results. HiveServer is built on Apache ThriftTM (http://thrift.apache.org/), therefore it is sometimes called the Thrift server although this can lead to confusion because a newer service named HiveServer2 is also built on Thrift.
For more details on how to connect to hive server(thrift server) see the link above.

What's a typical versioning strategy for RabbitMQ?

I've started working on a new project and we've been asked to build the system as a series of micro services, using RabbitMQ as a communication layer between them.
When developing REST APIs I tend to favour using the accepts HTTP header to control versioning and I see that you can use a header exchange in RabbitMQ to route messages in a similar way. However, as this is purely an internal messaging system, I'm not sure if the added complexity of a header exchange is really worth the while?
What is a typical setup for versioning RabbitMQ messages? It seems to me the options are:
New vhost for each version
Each Exchange has the version in the name (eg. MyExchange-v1, MyExchange-v2, ... etc.)
Queues are versioned
Routing keys are versioned (myroute-2.1.*)
Use a header exchange
Thanks for any input you may have.
I'd go with routing key version system for 2 main reasons:
Consumers will be able to bind (via queues of course) to their compatible versions via multiple bindings. Using semantic version (http://semver.org/) standard would be leveraged here via asterix and hash criteria.
You're not bound to using Rabbitmq as routing key is a standard function of AMQP

Apache Camel equivalent in Rails

Is there an equivalent to Apache Camel in Rails ?!
I'm creating an application that needs to "listen" to messages from one source (for example: email (POP3)) and sends them to another source (for example: logfile or email (using smtp)).
Any ideas ?
I am not sure about a complete equivalent to Apache Camel. But, to just listen for mails from a POP3 server and send to another source, try the mailman gem
EDIT: You should also look at mailcatcher gem
I am pretty sure there are no ports of Apache Camel to other languages, including ruby (but others as well, there was a question about .net recently). However, you can use Apache Camel with your application. You can treat Camel as an independent daemon that you need to configure and you can do that conveniently via xml. If you need some of your ruby code to be invoked during processing you can use the Camel org.jruby:jruby support. It may be less than ideal, but it works well. To interact with external systems Camel supports a large number of protocols already (including the ones you mentioned), but one could plug in her own.
Given Camel's support for many languages, protocols and data formats, I doubt anybody will go through the significant effort of porting it to other languages, but you never know.
You should definitely look at Llama.
They are in an early stage, but seems like they are going to build "an integration-framework on top of EventMachine that helps with tying together various backend services", which is what Camel is.