I have a ServiceFabric service hosting WebAPI. On a controller, I receive, in my Request, a FileStream. I have no problem reading the FileStream there.
Then, I want this WebAPI service to call another SF service (stateful) - let's call it Service2, giving a MemoryStream in parameter.
try
{
await _service2Proxy.MyService2Method(myMemoryStream, otherParameters);
// Line after
}
catch
{
// Error handling
}
And in the Service2
public Task MyService2Method(MemoryStream ms, string otherParam)
{
// Log line
// Do something
}
It works perfectly well with a File < 3 MB. Yet, with a file > 5 MB, the call doesn't work. We never go on // Line after, // Error handling or // Log line.
I did add [assembly: FabricTransportServiceRemotingProvider(MaxMessageSize = int.MaxValue)] on the controller assembly, the WebAPI service assembly and the Service2 assembly.
The Service2 interface has the [OperationContract] and [ServiceContract] attributes.
I also tried sending a byte[] instead of a MemoryStream. The problem is still the same.
If it's a StatefulService and you use some ReliableDictionary with huge data, it could lead to similar issues when SF replicates your dictionary data.
You can set two more settings to prevent this:
Set the MaxReplicationMessageSize when you create the service instance.
Init your ServiceReplicaListener with custom FabricTransportListenerSettings : MaxMessageSize
Code:
public MyStateFulService(StatefulServiceContext context)
: base(context, new ReliableStateManager(context, new ReliableStateManagerConfiguration(new ReliableStateManagerReplicatorSettings
{
MaxReplicationMessageSize = 1073741824
}))){ }
protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
{
var setting = new FabricTransportListenerSettings();
setting.MaxMessageSize = 1073741824;
return new[] { new ServiceReplicaListener(initParams => new FabricTransportServiceRemotingListener(initParams, this, setting), "RpcListener")};
}
Edit :
A highly better way to do this: In case you have authentication between replica, you should set these settings in Settings.xml.
<?xml version="1.0" encoding="utf-8" ?>
<Settings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<!-- This is used by the StateManager's replicator. -->
<Section Name="ReplicatorConfig">
<Parameter Name="ReplicatorEndpoint" Value="ReplicatorEndpoint" />
<Parameter Name="MaxReplicationMessageSize" Value="1073741824" />
</Section>
<!-- This is used for securing StateManager's replication traffic. -->
<Section Name="ReplicatorSecurityConfig">
<Parameter Name="CredentialType" Value="Windows" />
<Parameter Name="ProtectionLevel" Value="None" />
</Section>
<!-- Add your custom configuration sections and parameters here. -->
<!--
<Section Name="MyConfigSection">
<Parameter Name="MyParameter" Value="Value1" />
</Section>
-->
</Settings>
It works fine for us.
Makes sure you are setting the assembly attribute properly.
https://msdn.microsoft.com/en-us/library/4w8c1y2s(v=vs.110).aspx
Here is what we are doing.
using Microsoft.ServiceFabric.Services.Remoting.FabricTransport;
[assembly: FabricTransportServiceRemotingProvider(MaxMessageSize = 134217728)]
Again make sure this is available in the assembly that is creating the service remoting listener and the assembly that is calling it with ServiceProxy.
Alternatively, you can set the max message size programmatically when you create the listener, or in a settings.xml config file. See here for more info on that: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-secure-communication/
Related
My WCF service is locally hosted like this:
localhost/service.svc
On the server it's hosted like this:
servername/extra/service.svc
When making a request SwaggerWcf uses the base path and adds the configered elements:
localhost/user/parameter
But it should be:
localhost/extra/user/parameter
So I need WCF to not just use the hostname, but also a little more of the url.
I could add it to the SwaggerWcf configuration, which is user and could be extra/user. But then it won't work locally anymore.
I've tried adding a Config class that could read configuration attributes statically:
using System.Configuration;
namespace Project
{
public static class Config
{
public static readonly string SwaggerWcfRequestPath = ConfigurationManager.AppSettings["SwaggerWcf.RequestPath"] ?? "/user";
}
}
But when I try to use this:
[SwaggerWcf(Config.SwaggerWcfRequestPath)]
public class Service: IService
It still produces the same error:
Error 46 An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type.
How can this be done dynamically? Then it can be different for different environments.
Currently there is no way to do it
But I'll take a look into this later today
Probably the best way is allowing to override it using Web.config
<configSections>
<section name="swaggerwcf" type="SwaggerWcf.Configuration.SwaggerWcfSection, SwaggerWcf"/>
</configSections>
<swaggerwcf>
<settings>
<setting name="Host" value="www.msampleservice.com"/>
<setting name="BasePath" value="/myserviceapi"/>
</settings>
</swaggerwcf>
I am trying to monitor methods inside a .NET app which is a background process using New Relic for which I know I need to add Custom Instrumentation.
I have re-installed the .NET Agent, and after configuring "Instrument all .NET Applications", and making changes within the app.config and newrelic.config files, I am getting basic data of the background process in the new relic dashboard.
Now, to add Custom Instrumentation, I have added another instrumentation config file inside the extensions directory. Restarted the app, but still can't see the new/custom methods I am trying to monitor.
This is my instrumentation file MyInstrumentation.xml
<?xml version="1.0" encoding="utf-8"?>
<!-- instrument EngineService.BestAgentSolver.Solve inside EngineService.BestAgentSolver -->
<tracerFactory metricName="Cast-a-Net.EngineService.BestAgentSolver.Solve-Metric">
<match assemblyName="Cast-a-Net.EngineService" className="Cast-a-Net.EngineService.BestAgentSolver">
<exactMethodMatcher methodName="Solve" />
</match>
</tracerFactory>
<!-- instrument EngineService.SessonManager.BroadcastLeadCounts inside EngineService.SessionManager -->
<tracerFactory metricName="Cast-a-Net.EngineService.SessionManager.BroadcastLeadCounts-Metric">
<match assemblyName="Cast-a-Net.EngineService" className="Cast-a-Net.EngineService.SessionManager">
<exactMethodMatcher methodName="BroadcastLeadCounts" />
</match>
</tracerFactory>
<tracerFactory metricName="myapp.Web.Controllers.CallListController.ActionResult-Metric">
<match assemblyName="myapp.Web" className="myapp.Web.Controllers.CallListController">
<exactMethodMatcher methodName="ActionResult" />
</match>
</tracerFactory>
Am I missing a step or doing something wrong?
Custom instrumentation in the .NET agent works with web transactions that use the HttpContext object. Our .NET agent API, on the other hand, allows you to collect metrics that can be displayed in a custom dashboard. In particular, RecordMetric, RecordResponseTimeMetric, and IncrementCounter are useful because they work with non-web applications.
Starting with version 2.24.218.0 of the .NET agent however, a new feature can be used to create transactions where the agent would normally not do so. This is a manual process via a custom instrumentation file.
Create a custom instrumentation file named, say CustomInstrumentation.xml, in C:\ProgramData\New Relic.NET Agent\Extensions along side CoreInstrumentation.xml. Add the following content to your custom instrumentation file:
<?xml version="1.0" encoding="utf-8"?>
<extension xmlns="urn:newrelic-extension">
<instrumentation>
<tracerFactory name="NewRelic.Agent.Core.Tracer.Factories.BackgroundThreadTracerFactory" metricName="Category/Name">
<match assemblyName="AssemblyName" className="NameSpace.ClassName">
<exactMethodMatcher methodName="MethodName" />
</match>
</tracerFactory>
</instrumentation>
</extension>
You must change the attribute values Category/Name, AssemblyName, NameSpace.ClassName, and MethodName above:
The transaction starts when an object of type NameSpace.ClassName from assembly AssemblyName invokes the method MethodName. The transaction ends when the method returns or throws an exception. The transaction will be named Name and will be grouped into the transaction type specified by Category. In the New Relic UI you can select the transaction type from the Type drop down menu when viewing the Monitoring > Transactions page.
Note that both Category and Name must be present and must be separated by a slash.
As you would expect, instrumented activity (methods, database, externals) occurring during the method's invocation will be shown in the transaction's breakdown table and in transaction traces.
Here is a more concrete example. First, the instrumentation file:
<?xml version="1.0" encoding="utf-8"?>
<extension xmlns="urn:newrelic-extension">
<instrumentation>
<tracerFactory name="NewRelic.Agent.Core.Tracer.Factories.BackgroundThreadTracerFactory" metricName="Background/Bars">
<match assemblyName="Foo" className="Foo.Bar">
<exactMethodMatcher methodName="Bar1" />
<exactMethodMatcher methodName="Bar2" />
</match>
</tracerFactory>
<tracerFactory metricName="Custom/some custom metric name">
<match assemblyName="Foo" className="Foo.Bar">
<exactMethodMatcher methodName="Bar3" />
</match>
</tracerFactory>
</instrumentation>
</extension>
Now some code:
var foo = new Foo();
foo.Bar1(); // Creates a transaction named Bars in category Background
foo.Bar2(); // Same here.
foo.Bar3(); // Won't create a new transaction. See notes below.
public class Foo
{
// this will result in a transaction with an External Service request segment in the transaction trace
public void Bar1()
{
new WebClient().DownloadString("http://www.google.com/);
}
// this will result in a transaction that has one segment with a category of "Custom" and a name of "some custom metric name"
public void Bar2()
{
// the segment for Bar3 will contain your SQL query inside of it and possibly an execution plan
Bar3();
}
// if Bar3 is called directly, it won't get a transaction made for it.
// However, if it is called inside of Bar1 or Bar2 then it will show up as a segment containing the SQL query
private void Bar3()
{
using (var connection = new SqlConnection(ConnectionStrings["MsSqlConnection"].ConnectionString))
{
connection.Open();
using (var command = new SqlCommand("SELECT * FROM table", connection))
using (var reader = command.ExecuteReader())
{
reader.Read();
}
}
}
}
Here is a simple console app that demonstrates Custom Transactions:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Custom Transactions");
var t = new CustomTransaction();
for (int i = 0; i < 100; ++i )
t.StartTransaction();
}
}
class CustomTransaction
{
public void StartTransaction()
{
Console.WriteLine("StartTransaction");
Dummy();
}
void Dummy()
{
System.Threading.Thread.Sleep(5000);
}
}
}
Use the following custom instrumentation file:
<?xml version="1.0" encoding="utf-8"?>
<extension xmlns="urn:newrelic-extension">
<instrumentation>
<tracerFactory name="NewRelic.Agent.Core.Tracer.Factories.BackgroundThreadTracerFactory" metricName="Background/CustomTransaction">
<match assemblyName="ConsoleApplication1" className="ConsoleApplication1.CustomTransaction">
<exactMethodMatcher methodName="StartTransaction" />
</match>
</tracerFactory>
<tracerFactory metricName="Custom/Dummy">
<match assemblyName="ConsoleApplication1" className="ConsoleApplication1.CustomTransaction">
<exactMethodMatcher methodName="Dummy" />
</match>
</tracerFactory>
</instrumentation>
</extension>
After running the application a few times you should see a custom transaction in the Other Transactions, Background category. You should see the Dummy segment in the transactions breakdown table and transaction trace.
I tried this question in a generic way on this post: https://stackoverflow.com/q/18968846/147637
But that did not get us to the result.
Soooo, here it is concretely!
I have the code below. It works. In VS, you add a web reference, code up the below, and then.... start fiddling the app.config.
And it works.
But I need to get rid of the app config. It is a problem that crucial pieces of the code are not in the.... code. It is hard to document, and easy for folks looking at this example to forget to look in the app config (this is an example for other devs).
So the question is: How do I move the contents of app.config into code?
(I am a part part part time coder. Pointing me at generic documentation won't get me there, sorry to say!)
**// .cs file:**
using myNameSpace.joesWebService.WebAPI.SOAP;
namespace myNameSpace
{
class Program
{
static void Main(string[] args)
{
// create the SOAP client
joesWebServerClient server = new joesWebServerClient();
string payloadXML = Loadpayload(filename);
// Run the SOAP transaction
string response = server.WebProcessShipment(string.Format("{0}#{1}", Username, Password), payloadXML);
=================================================
**app.config**
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<!-- Some non default stuff has been added by hand here -->
<binding name="IjoesWebServerbinding" maxBufferSize="256000000" maxReceivedMessageSize="256000000" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://joesWebServer/soap/IEntryPoint"
binding="basicHttpBinding" bindingConfiguration="IjoesWebServerbinding"
contract="myNameSpace.joesWebService.WebAPI.SOAP.IjoesWebServer"
name="IjoesWebServerSOAP" />
</client>
</system.serviceModel>
</configuration>
Generally speaking, a config file is preferred over hard-coding the settings because all you need to do with a config file is change the values you want to change and then restart the application. If they're hardcoded, you have to modify the source, recompile and redeploy.
Having said that, you can pretty much do everything in code that you do in the config file for WCF (I seem to recall a few exceptions, but don't remember them off hand).
One way to achieve what you're looking for is to define the binding in your code and create the client via ChannelFactory<T>, where T is the interface for your service (more accurately the service contract, which is usually in an interface and then implemented by a class).
For example:
using System.ServiceModel;
using myNameSpace.joesWebService.WebAPI.SOAP;
namespace myNameSpace
{
class Program
{
static void Main(string[] args)
{
// Create the binding
BasicHttpBinding myBinding = new BasicHttpBinding();
myBinding.MaxBufferSize = 256000000;
myBinding.MaxReceivedMessageSize = 256000000;
// Create the Channel Factory
ChannelFactory<IjoesWebServer> factory =
new ChannelFactory<IjoesWebServer>(myBinding, "http://joesWebServer/soap/IEntryPoint");
// Create, use and close the client
IjoesWebService client = null;
string payloadXML = Loadpayload(filename);
string response;
try
{
client = factory.CreateChannel();
((IClientChannel)client).Open();
response = client.WebProcessShipment(string.Format("{0}#{1}", Username, Password), payloadXML);
((IClientChannel)client).Close();
}
catch (Exception ex)
{
((ICientChannel)client).Abort();
// Do something with the error (ex.Message) here
}
}
}
Now you don't need a config file. The additional settings you had in the example are now in the code.
The advantage of ChannelFactory<T> is that once you create an instance of the factory, you can generate new channels (think of them as clients) at will by calling CreateChannel(). This will speed things up as most of your overhead will be in the creation of the factory.
An additional note - you're using I<name> in a lot of places in your config file. I usually denotes an interface, and if a full time developer were to look at your project it might be a little confusing for them at first glance.
With WCF 4.5, if you add a static config method to your WCF service class, then it will load automatically and ignore what's in app.config file.
<ServiceContract()>
Public Interface IWCFService
<OperationContract()>
Function GetData(ByVal value As Integer) As String
<OperationContract()>
Function GetDataUsingDataContract(ByVal composite As CompositeType) As CompositeType
End Interface
Public Class WCFService
Implements IWCFService
Public Shared Function CreateClient() As Object
End Function
Public Shared Sub Configure(config As ServiceConfiguration)
'Define service endpoint
config.AddServiceEndpoint(GetType(IWCFService), _
New NetNamedPipeBinding, _
New Uri("net.pipe://localhost/WCFService"))
'Define service behaviors
Dim myServiceBehaviors As New Description.ServiceDebugBehavior With {.IncludeExceptionDetailInFaults = True}
config.Description.Behaviors.Add(myServiceBehaviors)
End Sub
Public Function GetData(ByVal value As Integer) As String Implements IWCFService.GetData
Return String.Format("You entered: {0}", value)
End Function
Public Function GetDataUsingDataContract(ByVal composite As CompositeType) As CompositeType Implements IWCFService.GetDataUsingDataContract
End Function
End Class
I'm still looking into how to do the same for the client. I'll try to update when I figure it out if there's any interest.
I have a .wsdl file that my web service (old asmx style) must implement. That is taken care of. When I publish the web service you can call it with ?wsdl parameter to get a generated wsdl.
How do I include my .wsdl file so that is the one that is returned instead of the generated one?
Is it possible to do with an attribute in my web service class?
Is it a given to stay with "old-style" ASMX? Or could you move up to WCF? That's really the most current webservice offering by Microsoft, and if you're doing something new and you're on .NET 3.0 or higher - why spend time on "old" technology?
In WCF, you could definitely define a static physical WSDL file to be used by clients connecting to your metadata endpoint (your "...?wsdl" URL). Not sure if you can do it in ASMX, too.
OK, on ASMX / .NET 2.0, you could of course always put the actual WSDL file under the root of your web site, and then just reference it like this:
http://yourwebserver/YourVirtDir/MyService.wsdl
I don't know if there's a way to "redirect" the
http://yourwebserver/YourVirtDir/MyService.asmx?wsdl
call to go to that fixed URL instead. I'm sure someone else will know, though!
Marc
To avoid the confusion of having two different WSDLs available on two different URLs (i.e., the *.asmx?wsdl URL and a custom URL) in your web service application, you could write an HttpModule that intercepts the request to the *.asmx?wsdl URL and returns your custom WSDL instead.
EDIT: Here's an example, adapted and simplified from some code I previously wrote that makes a custom WSDL available at the standard *.asmx?wsdl URL.
using System;
using System.IO;
using System.Web;
using System.Web.Services.Configuration;
namespace DemoWebService
{
public class CustomWsdlModule :
IHttpModule
{
public void
Init(HttpApplication application)
{
// hook up to BeginRequest event on application object
application.BeginRequest += new EventHandler(this.onApplicationBeginRequest);
}
public void
Dispose()
{
}
private void
onApplicationBeginRequest(object source, EventArgs ea)
{
HttpApplication application = (HttpApplication)source;
HttpRequest request = application.Request;
HttpResponse response = application.Response;
// check if request is for WSDL file
if ( request.Url.PathAndQuery.EndsWith(".asmx?wsdl", StringComparison.InvariantCultureIgnoreCase) )
{
// if Documentation protocol is not allowed, throw exception
if ( (WebServicesSection.Current.EnabledProtocols & WebServiceProtocols.Documentation) == 0 )
{
throw new System.InvalidOperationException("Request format is unrecognized.");
}
// get path to physical .asmx file
String asmxPath = request.MapPath(request.Url.AbsolutePath);
// build path to .wsdl file; should be same as .asmx file, but with .wsdl extension
String wsdlPath = Path.ChangeExtension(asmxPath, ".wsdl");
// check if WSDL file exists
if ( File.Exists(wsdlPath) )
{
// read WSDL file
using ( StreamReader reader = new StreamReader(wsdlPath) )
{
string wsdlFileContents = reader.ReadToEnd();
// write WSDL to response and end response without normal processing
response.ContentType = "text/xml";
response.Write(wsdlFileContents);
response.End();
}
}
}
}
}
}
This simplified code assumes that your custom WSDL is in the same folder as your .asmx file with a .wsdl extension. The HttpModule needs to be hooked into your web service application via the web.config file:
<?xml version="1.0"?>
<configuration>
<!-- ... -->
<system.web>
<!-- ... -->
<httpModules>
<add
type="DemoWebService.CustomWsdlModule"
name="CustomWsdlModule"/>
<!-- ... -->
</httpModules>
<!-- ... -->
</system.web>
<!-- ... -->
</configuration>
You can generate a WSDL and DISCO file by pointing the disco.exe tool that ships with the .NET Framework at your web service.
disco.exe http://webserver/MyWebService.asmx
The following files are created:
results.discomap
MyWebService.disco
MyWebService.wsdl
I would like to make a RESTful app of HTTPhandlers without having to define every endpoint by making an entry in the web.config, i'd like the style of attaching attributes to a class constructor eg:
public class obj : IHttpHandler
{
[WebGet(UriTemplate = "/accounts/{id}")]
public obj(string id)
{
// this is just an eg, it worild normally include caching and
// a template system
String html = File.ReadAllText("/accounts/accounts.htm");
html.replace("id", id);
httpcontext.current.response.write(html)
}
}
instead of
<httpHandlers>
<clear />
<add verb="GET" path="/accounts/*" type="MyApp.obj" />
</httphandlers>
The way i'm doing it now i have 100's of endpoints in the web.config :( i'd rather define them in the class. And i don't want to make extra files (.asmx) either. I'd like an app of just .htm files with tokens and .cs files
Thanks!
You could automate the registration of the endpoints and so on, with a custom ServiceHost, which overrides the ApplyConfiguration() method, which then virtualizes the configuration so that it does not have to be in the web.config file.
Here's a starting point. It doesn't do exactly what you want, but it illustrates the concept of virtualizing the configuration.