I'm trying to add a gRPC health check endpoint in tensorflow serving. I added these code into tensorflow_serving/model_servers/server.cc and re-compiled it:
::grpc::EnableDefaultHealthCheckService(true);
::grpc::reflection::InitProtoReflectionServerBuilderPlugin();
After that I run it and test with grpcurl: grpcurl -plaintext localhost:8500 list
It shows:
grpc.health.v1.Health
grpc.reflection.v1alpha.ServerReflection
tensorflow.ProfilerService
tensorflow.serving.ModelService
tensorflow.serving.PredictionService
But when I try grpcurl -plaintext localhost:8500 grpc.health.v1.Health/Check
It says:
Error invoking method "grpc.health.v1.Health/Check": target server does not expose service "grpc.health.v1.Health"
It's quite a simple feature but have been stucking me for several days.
Could someone help? Thanks in advance!
Simply speaking, grpcurl relies on reflection service if you don't provide proto files and gRPC C++ doesn't expose reflection data for health service, which is why you got this head-scratching error in the first place.
$ grpcurl -plaintext 0.0.0.0:50051 grpc.health.v1.Health/Check
Error invoking method "grpc.health.v1.Health/Check": target server does not expose service "grpc.health.v1.Health"
grpcurl can do health-check call with health proto file present;
$ grpcurl -plaintext -proto=src/proto/grpc/health/v1/health.proto 0.0.0.0:50051 grpc.health.v1.Health/Check
{
"status": "SERVING"
}
Implementation-wise, gRPC C++ relies on protobuf description pool to implement its reflection service but health is based on upb which is not part of protobuf description pool. This is why gRPC C++ isn't able to expose the schema of health service.
Related
I am uanble to add the below Java service reference in WCF Client
https://filetransfer.nordea.com/services/CorporateFileService
getting below error .
There was an error downloading 'https://filetransfer.nordea.com/services/CorporateFileService/$metadata'. The request failed with the error:
I opened the port 8000. still getting same issue.
Please let me know what is the issue.
Thanks
Jaya
Please note that a WCF service normally expose a file called a WSDL(Web Services Description Language) - this file explains the methods that you will use with the service
https://www.w3.org/TR/2001/NOTE-wsdl-20010315
Normally an endpoint needs to be created and be accessible for ypu to be able to view the service, what I would suggest is that if WCF doesnt seem to be doing that for you, try adding the service as a webservice Reference in your C#/Java project.
https://www.blackbaud.com/files/support/guides/infinitydevguide/Subsystems/infGC-developer-help/Content/AddingWebReference.htm
Is it possible to link/connect/ send a signal from JavaScript code into Solidity/Ethereum?
You can use web3.
There is a different syntax for interfacing with contracts. Depending on if the contract is already deployed or you need to do that yourself.
When you have the contract instance you can then call contract methods.
const ChessGame = web3.eth.contract(abiArray);
const contractInstance = ChessGame.at(address);
contractInstance.declareWinner(winner, function (err, res) {
// do something
});
I personally think web3 is a little cumbersome. I recommend checking out Truffle and following some of their tutorials to get up to speed.
You could install the official Go implementation of the Ethereum protocol, geth.
Geth is a tool for running a local node/miner and also allows you to connect to a running blockchain via the console (which then becomes a Javascript console) and input RPC calls natively via the provided web3 package.
Geth also supports connecting to test nets (such as Ropsten or Rinkeby) or even a private blockchain on localhost.
Additionally to a user interacting directly with the console via the command line, geth can be configured from a shell script/batch file to both run or preload javascript files containing scripted commands for testing!
yes just create an ABI of your smart contract and then interact with your smart contracts however you see fit via web3.
I am trying to unit test message handlers for NServiceBus 4.0.4. The bus is configured to use JSON serializer in the application using the Configure.Serialization.Json(); method call.
Whenever I call the Test.Initialize() method from the unit tests assembly I get the following exception: System.Configuration.ConfigurationErrorsException : Multiple serializers are not supported. Please make sure to only enable one
I tried calling Configure.Serialization.Json() and Serializers.SetDefault<JsonSerialization>() before calling the Test.Initialize() method without any success.
Does anyone know what am I doing wrong? All examples I see on the internet do not mention any Configure calls.
This issue has been reported previously here and looks like it will be fixed in the next NServiceBus build (both 4.0.5 and 4.1.0)
A workaround is to explicitly disable the xml serializer when enabling the json one.
Configure.Serialization.Json();
Feature.Disable<XmlSerialization>(); // hack to make NSB unit tests work
I have a sharp architecture project and I am making use of ApplicationServices in it as well.
There is requirement to provide a winform client that will use a wcf service. The wcf service will in turn use the ApplicationServices. I have not started working on the winform client yet but I am working on the wcf service.
Following the Northwind sample. I have created a "Wcf Service library" project and a "Wcf Service Application" project in my solution.
I am new to wcf but i know all the basics and have worked with web services alot in the past. I have following questions:-
1) I would like to know why there is a need of two projects, wcf library and wcf application?
2) I have noticed that the ITerritoriesWcfService interface in the Northwind sample inherits ICloseableAndAbortable.
public interface ITerritoriesWcfService : ICloseableAndAbortable
What is the purpose of ICloseableAndAbortable?
3) There is another class TerritoriesWcfServiceClient
public partial class TerritoriesWcfServiceClient : ClientBase<ITerritoriesWcfService>, ITerritoriesWcfService
What is the purpose of this class?
4) In the TerritoriesService.svc file, what is the purpose of Factory="SharpArch.Wcf.NHibernate.ServiceHostFactory, SharpArch.Wcf" ? Usually in a normal wcf service application, I use codebehind attribute, but since the .cs file actually resides int the wcf service library project, I would like to know what following code is doing?
<%# ServiceHost Language="C#" Debug="true"
Service="Northwind.Wcf.TerritoriesWcfService"
Factory="SharpArch.Wcf.NHibernate.ServiceHostFactory, SharpArch.Wcf" %>
Even if I remove the above Factory attribute, I can still run the service app project and test the service using WcfTestClient utility.
6) When i run my service and using WcfTestClient If I run a method twice that accesses a repository, then on the second call, I get an ObjectDisposedException.
{"Session is closed!\r\nObject name: 'ISession'."}
I believe the NHibernate Session is getting disposed after the first call. How can reinitialise for each call or should I keep it open? I would like to know the best practice?
7) Also If I run the Northwind.Wcf.Web project and click on TerritoriesService.svc
file on the Directory Listing screen, I get the following error
{"Method 'Generate' in type 'Northwind.Data.NHibernateMaps.AutoPersistenceModelGenerator' from assembly 'Northwind.Data, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.":"Northwind.Data.NHibernateMaps.AutoPersistenceModelGenerator"}
I don't understand why is it throwing this error, when i already got the method and the Northwind.Web works fine too.
Awaiting
Nabeel
1) Strictly, you can combine the WCF library and the WCF application
in one assembly. This would mean that you would combine the contracts
and the implementations in one assembly.
If you are using svcutil.exe or Visual Studio (which uses svcutil.exe
in turn) to generate proxy classes for your client, you'd be fine
because the proxy classes are generated from discovery of your
services.
If however, you want to use your own classes for transport, which is
quite common in DTO scenarios and the like, you'd need to reference a
shared library from both the client and the server. If that shared
library would be your combined library/application assembly, the
client would get the application implementation in scope (because it
references the assembly that contains the contracts) and that's really
not something you'd want. The client needs to know as little as
possible about the server, just as much as the contracts expose --
that's what the contracts are for in the first place.
I think it is best practice to separate interfaces/contracts from
implementation anyway because it leads to better separation of
concerns. It's just that most parts of your solution don't need (and
shouldn't) know HOW something is done, just WHAT that something can
do. There are many more advantages over this, such as improved
testability.
2) Taken from the code documentation of ICloseableAndAbortable:
"When implemented by your WCF contracts, they are then interchangable
with WCF client proxies. This makes it simpler to use dependency
injection and to mock the WCF services without having to worry about
if it's a WCF client when you go to close/abort it.".
I think that says it all.
3) The client class is, like the code documentation says, a strongly
typed client proxy. It can be used by clients to talk to the server,
providing a strongly typed class that has members that correspond to
the service operations that can be called on the server.
The advantage of this class is that you don't need to use the
svcutil.exe generated proxy classes. This what they mean by not having
to configure it via WCF configuration. This allows you to ship proxy
classes to your clients so they can immediately talk to your server
instead of generating proxy classes first. It allows for more control
as well, changing the code that is generated by the proxy class is
really not something you'd want to do.
This again is a good reason to put the interfaces/contracts in a
separate assembly because you don't want to ship the service
implementation code to your clients.
4) The service host factory creates a service instance based on the
provided service type. This can come in handy if you want to put the
service code somewhere other than in the code behind file. You'd also
need it if you are using Depency Injection, you'd provide the service
contract interface as the type and the SharpArch.Wcf service host
factory resolves it to the correct implementation class type by means
of the DI framework (Castle Windsor in SA). You can think of this as a
means of getting hold of a service implementation while not caring
about where it actually is coming from.
In this case, the service will run when you remove the factory
attribute, because the default factory is able to resolve the service
type. You're bypassing on stuff like DI and session management though,
exactly that what makes SA valueable.
5) I'll have to skip this one because apparently there is no question number 5 :-)
6) As in the Northwind sample project, you are probably using the ServiceHostFactory that comes with SA. With this service host factory, each created service instance is extended by a behavior that closes the NHibernate session directly after it's called. That okay by itself but chances are that your proxy clients are not managed in a transient way by Castle Windsor. Therefore instances get reused, including the closed sessions they (still) contain. Decorate your client proxy classes with the Transient attribute (Castle.Core.TransientAttribute) and Castle Windsor will create a fresh instance every time a service call is performed.
Apparently, there is a second way to solve this but it requires modification of the S#arpArchitecture code base. See WCF connections which process more than one request fail because the nhibernate session is closed and isn't re-opened. on GitHub.
7) I'm sorry, I seriously have no idea. I might look into this later.
I am using the Silvelight Business Application template. I wrote a function which uses Membership.getUserList function to return the user list. I tried exposing it as Service using WCF. But when I try to compile the client side code it throws a warning saying "Client Proxy Generation for user_authentication.Web.Service1 failed'. Why does it happen?
The complete warning message is:
Warning 4 Client proxy generation for
service
'user_authentication.Web.Service1'
failed: Generating metadata files...
Warning: Unable to load a service with
configName
'user_authentication.Web.Service1'. To
export a service provide both the
assembly containing the service type
and an executable with configuration
for this service.
Details:Either none of the assemblies passed were executables
with configuration files or none of
the configuration files contained
services with the config name
'user_authentication.Web.Service1'.
Warning: No metadata files were
generated. No service contracts were
exported. To export a service, use
the /serviceName option. To export
data contracts, specify the
/dataContractOnly option. This can
sometimes occur in certain security
contexts, such as when the assembly is
loaded over a UNC network file share.
If this is the case, try copying the
assembly into a trusted environment
and running it.
Hard to say, I'm not a good enough clairvoyant yet ;-) ... Is your webservice actually already compiled, published and running? Maybe here you can find further hints:
MSDN WCF Forums: svcutil Error