I'm comparing capabilities of ServiceStack.Redis and StackExchange.Redis clients.
I thought that it might be very useful to use IRedisTypedClient<T> class of ServiceStack.Redis client.
Just wondering if is there any equivalent of IRedisTypedClient<T> class in StackExchange.Redis client which provides auto serialization/deserialization of objects?
Related
I am using the library com.azure.spring:azure-spring-boot-starter-servicebus-jms:3.14.0 and I am trying to avoid the usage of a connection string by using a managed identity, but I wasn't able to find anything related on the internet. I also examined the library and I haven't seen any support for TokenCredential what Microsoft usually supports.
So the question is whether it is currently supported by the library or not?
In short, no.
The JMS API itself has no support for a "managed identity" or any kind of TokenCredetial object.
The JMS client implementation used here is Qpid JMS and it also has no support for a "managed identity" or any kind of TokenCredetial object.
Does anyone know of any benchmarks of using the native Elasticsearch driver over the rest client? I'm specifically working with the Java client but any other language would be fine.
If you are using Java then you can use native java client, which would be faster than HTTP Client. But if you are using any other language, then use REST Client would be faster, since client libraries in most programming languages use the HTTP Client themselves.
When using the an instance of the DataServiceContext class to materialise objects from an odata endpoint where the endpoint exposes some custom annotations, how does one get hold of the annotations data. I can't see any obvious extensibility points.
Custom annotations aren't exposed as a first-class concept on the DataServiceContext, but you can access them by hooking into the client response processing pipeline. This code will run after every entity is finished being read:
context.Configurations.ResponsePipeline.OnEntryEnded(
entryArgs => DoSomething(entryArgs.Entry.InstanceAnnotations));
Internally, the WCF Data Services Client uses a lower-level library called ODataLib (aka Microsoft.Data.OData on NuGet). The response and request pipelines allow you to dip into that lower level to get extra information when you need it, but you still get all the conveniences of using the full-fledged WCF Data Services client library. The classes like ODataEntry, ODataFeed, etc. that you work with on the processing pipelines are all part of the ODataLib API.
Does anyone has a good comparison between the two technologies: Thrift vs JMS, in Java for messaging services? Thanks!
Thrift is serialization/rpc framework whereas JMS is full-featured messaging service, so they don't compare directly.
JMS uses stardart java object serialization for ObjectMessage's. It's much slower than thrift and can't be deserialized without java. However, it's possible to serialize objects with any other framework and send them in the form of BytesMessage. For example, ActiveMQ encourages usage of protocol buffers for this task, but it's possible to use any other framework, like thrift, avro, kryo or smile.
This page might give an insight on speed/serialization size of different technologies:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
In general, each of modern serialization frameworks has its pros and cons, but they provide approximately the same performance.
Anyone aware of any good examples/resources using WCF to interact with Oracle AQ (Advanced Queueing), possibly even a custom binding?
Thanks.
To my mind WCF solves the same problems as OracleAQ can provide. WCF is tightly coupled by data contracts and can be bound to multiple transport types. OracleAQ is configurable by data contract (via registered XSD) or use a RAW xml queue. I am not aware of customer binding to differing transport mechanisms for OracleAQ and is very well documented and supported by ODAC. This wasn't the case for OO4O chatting to 9i but that's another story...
I would consider expending effort on implementing OracleAQ support within the client connection as this follows a similar overall pattern to WCF. Putting a service in between OracleAQ and the client endpoint to translate bindings doesn't appear to make sense other than introducing a level of complexity.