So, our project has recently started using Server Sent Events in ServiceStack. Our projects also log with log4net, using the log4net provider. Now that I've gotten through a couple of components using SSE, I am wondering if anyone else is thinking what I am here...
I typically use the 'DEBUG' level of log4net for a real chatty, 'debug' experience. When I'm on dev servers, or when I'm trying to get to the bottom of an issue... I'll change the logging level to 'DEBUG' and go to town. While I wouldn't run in higher environments using 'DEBUG' - I find that same level of information is what I might be interested in sending to a client. I have some long-running processes in a service, and it communicates with the web dashboard via SSE to report updates. I'm finding that the type of information that I would typically log to 'DEBUG' is generally what I would like to send to my dashboard. As you can then imagine, my code starts to look like this, and in many areas:
var msg = $"Processed {count} records.";
MessageLog.Debug(msg);
ServerEvents.NotifyChannel(channelName, selector, msg);
Seeing this makes me want to create a thin wrapper to enable the message to be sent to either the log, the SSE, or both with a single call. Does this type of setup exist in ServiceStack at present? I realize it's high level and there's details to work out (logging level, channel and selector values) but I have to believe there is some way to simplify this.
There isn't anything built-in, there are a couple ways you could implement this, my preference would be to use an extension method which takes an ILog, e.g:
public static void NotifyChannel(this IServerEvents server,
string channel, string selector, object message, ILog log)
{
if (log.IsDebugEnabled)
log.Debug(message);
server.NotifyChannel(channel, selector, message);
}
Or you could create an adapter IServerEvents class that you can register as a separate dependency, e.g:
container.Register(c =>
new LoggingServerEvents(c.Resolve<IServerEvents>()));
Which logs and delegates API calls to the IServerEvents dependency, e.g:
class LoggingServerEvents : IServerEvents
{
private static ILog Log = LogManager.GetLogger(typeof(LoggingServerEvents));
private IServerEvents sse;
public LoggingServerEvents(IServerEvents sse) => this.sse = sse;
public void NotifyChannel(string channel, string selector, object message)
{
if (Log.IsDebugEnabled)
Log.Debug(message);
sse.NotifyChannel(channelName, selector, message);
}
//...
}
Which you can reference in your Services like a normal dependency that you can use instead of ServerEvents when you want the message to also be logged, e.g:
public class MyServices : Service
{
public LoggingServerEvents LoggingServerEvents { get; set; }
public object Any(MyRequest request)
{
//ServerEvents.NotifyChannel(channelName, selector, msg);
LoggingServerEvents.NotifyChannel(channelName, selector, msg);
}
}
Related
I'm trying to log some basic gql method details - resolver/operation name and duration. I've started looking at using .AddHttpRequestInterceptor((context, executor, builder, ct)
and getting the info from the builder, but even though I can see it in the debugger, the method name is buried in private members like:
((HotChocolate.Execution.QueryRequestBuilder)builder)._query.Document.Definitions[0].SelectionSet.Selections[0].Name.Value
I'm sure there's an easier and better way to hook into the pipeline to get the method name and log it with the call duration.
I found an article written about GraphQL.Net that uses DefaultGraphQLExecuter -
public class GraphQLExecutorWithDiagnostics<TSchema> : DefaultGraphQLExecuter<TSchema>
which provides an operationName parameter within the
Task<ExecutionResult> ExecuteAsync(
, which looks ideal.
I'll be logging to AppInsights, but that's not relevant for now, I just want to get the info first.
I'm using v11.0.8
What you are looking for is the DiagnosticEventListener
You can just extend this base class and override the methods that you need for you logging.
public class CustomDiagnosticListener : DiagnosticEventListener
{
public override IActivityScope ExecuteRequest(IRequestContext context)
{
return EmptyScope;
}
public virtual IActivityScope ResolveFieldValue(IMiddlewareContext context)
{
return EmptyScope;
}
}
To use this diagnostic listener you have to add it to the schema
services.AddGraphQLServer()
...
.AddDiagnosticEventListener<CustomDiagnosticListener>()
In case you have dependencies that you listener has to reslove you have to reslove them manually:
services.AddGraphQLServer()
...
.AddDiagnosticEventListener<CustomDiagnosticListener>(
sp => new CustomDiagnosticListener(
sp.GetApplicationService<MyDependency>()))
In my application I have multiple custom Spring Application Events. I want to log every instance of these events occurring. Is there a way to do this automatically or do I have to manually log it every time?
You might create an event listener for the type of events you're interested in and log the event. Spring will register this listener and you'll basically done:
#Component
public class CustomEventListener implements ApplicationListener<CustomEvent> {
private static final Logger logger = ...;
#Override
public void onApplicationEvent(CustomEvent event) {
LOGGER.info("Got event: {}" , event);
}
}
However, you can't really use the same listener subscribed to multiple types of event unless they have an hierarchy (inheritance from some base event) You might be interested to read this thread it provides technical solutions in various cases.
Note: read the end of the answer for the way I implemented #Nonika's suggestions
What's the "right way" to send a websocket event on data insert?
I'm using a Spring Boot server with SQL/JPA and non-stomp websockets. I need to use "plain" websockets as I'm using Java clients where (AFAIK) there's no stomp support.
When I make a change to the database I need to send the event to the client so I ended up with an implementation like this:
#Transactional
public void addEntity(...) {
performActualEntityAdding();
sendEntityAddedEvent(eventData);
}
#Transactional
public void sendEntityAddedEvent(String eventData) {
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
#Override
public void afterCommit() {
sendEntityAddedEventAsync(eventData);
}
});
}
#Async
public void sendEntityAddedEventAsync(String eventData) {
// does the websocket session sending...
}
This works. If I would just call the sendEntityAddedEventAsync it would also work for real world scenarios but it fails on unit tests because the event would arrive before transaction commit. As such when the unit test invokes a list of the entities after the event it fails.
This feels like a hack that shouldn't be here. Is there a better way to ensure a commit?
I tried multiple alternative approaches and the problem is that they often worked for 10 runs of the unit tests yet failed every once in a while. That isn't acceptable.
I tried multiple approaches to solve this such as different transaction annotations and splitting the method to accommodate them. E.g read uncommitted, not supported (to force a commit) etc. Nothing worked for all cases and I couldn't find an authoritative answer for this (probably common) use case that wasn't about STOMP (which is pretty different).
Edit
One of my original attempts looked something like this:
// this shouldn't be in a transaction
public void addEntity(...) {
performActualEntityAdding();
sendEntityAddedEvent(eventData);
}
#Transactional
public void performActualEntityAdding(...) {
//....
}
#Async
public void sendEntityAddedEventAsync(String eventData) {
// does the websocket session sending...
}
The assumption here is that when sendEntityAddedEventAsync is invoked the data would already be in the database. It wasn't for a couple of additional milliseconds.
A few additional details:
Test environment is based on h2 (initially I mistakenly wrote hsql)
Project is generated by JHipster
Level 2 cache is used but disabled as NONE for these entities
Solution (based on #Nonika's answer):
The solution for me included something similar to this:
public class WebEvent extends ApplicationEvent {
private ServerEventDAO event;
public WebEvent(Object source, ServerEventDAO event) {
super(source);
this.event = event;
}
public ServerEventDAO getEvent() {
return event;
}
}
#Transactional
public void addEntity(...) {
performActualEntityAdding();
applicationEventPublisher.publishEvent(new WebEvent(this, evtDao));
}
#Async
#TransactionalEventListener
public void sendEntityAddedEventAsync(WebEvent eventData) {
// does the websocket session sending...
}
This effectively guarantees that the data is committed properly before sending the event and it runs asynchronously to boot. Very nice and simple.
Spring is using AdviceMode.PROXY for both #Async and #Transactional this is quote from the javadoc:
The default is AdviceMode.PROXY. Please note that proxy mode allows
for interception of calls through the proxy only. Local calls within
the same class cannot get intercepted that way; an Async annotation on
such a method within a local call will be ignored since Spring's
interceptor does not even kick in for such a runtime scenario. For a
more advanced mode of interception, consider switching this to
AdviceMode.ASPECTJ.
This rule is common for almost all spring annotations which requires proxy to operate.
Into your first example, you have a #Transactional annotation on both addEntity(..) and performActualEntityAdding(..). I suppose you call addEntity from another class so #Transactional works as expected. process in this scenario can be described in this flow
// -> N1 transaction starts
addEntity(){
performActualEntityAdding()//-> we are still in transaction N1
sendEntityAddedEvent() // -> call to this #Async is a class local call, so this advice is ignored. But if this was an async call this would not work either.
}
//N1 transaction commits;
That's why the test fails. it gets an event that there is a change into the db, but there is nothing because the transaction has not been committed yet.
Scenario 2.
When you don't have a #Transactional addEntity(..) then second transaction for performActualEntityAdding not starts as there is a local call too.
Options:
You can use some middleware class to call these methods to trigger
spring interceptors.
you can use Self injection with Spring
if you have Spring 5.0 there is handy #TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
We are faced with the task to convert a REST service based on custom code to Web API. The service has a substantial amount of requests and operates on data that could take some time to load, but once loaded it can be cached and used to serve all of the incoming requests. The previous version of the service would have one thread responsible for loading the data and getting it into the cache. To prevent the IIS from running out of worker threads clients would get a "come back later" response until the cache was ready.
My understanding of Web API is that it has an asynchronous behavior built in by operating on tasks, and as a result the number of requests will not directly relate to the number of physical threads being held.
In the new implementation of the service I am planning to let the requests wait until the cache is ready and then make a valid reply. I have made a very rough sketch of the code to illustrate:
public class ContactsController : ApiController
{
private readonly IContactRepository _contactRepository;
public ContactsController(IContactRepository contactRepository)
{
if (contactRepository == null)
throw new ArgumentNullException("contactRepository");
_contactRepository = contactRepository;
}
public IEnumerable<Contact> Get()
{
return _contactRepository.Get();
}
}
public class ContactRepository : IContactRepository
{
private readonly Lazy<IEnumerable<Contact>> _contactsLazy;
public ContactRepository()
{
_contactsLazy = new Lazy<IEnumerable<Contact>>(LoadFromDatabase,
LazyThreadSafetyMode.ExecutionAndPublication);
}
public IEnumerable<Contact> Get()
{
return _contactsLazy.Value;
}
private IEnumerable<Contact> LoadFromDatabase()
{
// This method could be take a long time to execute.
throw new NotImplementedException();
}
}
Please do not put too much value in the design of the code - it is only constructed to illustrate the problem and is not how we did it in the actual solution. IContactRepository is registered in the IoC container as a singleton and is injected into the controller. The Lazy with LazyThreadSafetyMode.ExecutionAndPublication ensures only the first thread/request is running the initialization code, the following rquests are blocked until the initialization completes.
Would Web API be able to handle 1000 requests waiting for the initialization to complete while other requests not hitting this Lazy are being service and without the IIS running out of worker threads?
Returning Task<T> from the action will allow the code to run on the background thread (ThreadPool) and release the IIS thread. So in this case, I would change
public IEnumerable<Contact> Get()
to
public Task<IEnumerable<Contact>> Get()
Remember to return a started task otherwise the thread will just sit and do nothing.
Lazy implementation while can be useful, has got little to do with the behaviour of the Web API. So I am not gonna comment on that. With or without lazy, task based return type is the way to go for long running operations.
I have got two blog posts on this which are probably useful to you: here and here.
I have a Mvc3-Project where I want to register to custom event hooks.
So that I can register to an event like "User logon". I do not want to do it in the controller, because there is a business logic behind it in an other project.
So in my Mvc3-Project I want to write some classes that will have the code that has to be executed when a User is loged on. But how do I register these classes (or an instance of them) to the event. Is it a good idea to use reflection an search for all classes inherited from a special base class, or is there an other smarter way?
So again, I do not want to monitor the action that is called, I want that the business logic triggers some classes in my Mvc3-Project.
EDIT
As Chris points out in the comments below, MVC3 is stateless, meaning that with this solution you would have to resubscribe for these events on every request. This is probably not a very good solution for MVC.
Have you considered an global event service?
Rough example:
class Example : IEventReceiver
{
public void Init()
{
EventService.Subscribe("Logon", this);
}
private void OnEvent(string eventName)
{
// Do logon stuff here.
}
}
You would need to create the EventService class, which might be a singleton or service. It might have interface similar to the following:
public interface IEventService
{
void Subscribe(string eventName, IEventReceiver receiver);
void Unsubscribe(string eventName, IEventReceiver receiver);
void DispatchEvent(string eventName);
}
public interface IEventReceiver
{
void OnEvent(string eventName);
}