I have recently used Mailkit lib in our project in order replacing .NET SmtpClient.
We have 2 business cases to use the SmtpClient to send emails.
In one instance we use SmtpClient to send queued emails in a separate process and other instance we send emails instantly.
While implementing I noticed that we have to call the Disconnect method of the Client instance.
mailClient.Disconnect(...);
It was not sure and not clear in the documentation what is the best way to call this method.
So my question, What is the best practice to use this method?
Call mailClient.Disconnect(true) per every message or mailClient.Disconnect(false)?
Out of interest, if I use the client within a using block, should I require to call Disconnect(...) explicitly after sending a message? I reckon it calls disconnect implicitly when the Dispose() gets executed.
using (var mailClient = new SmtpClient())
{
mailClient.Connect(...);
mailClient.AuthenticationMechanisms.Remove("XOAUTH2");
mailClient.Authenticate(...);
mailClient.Send(message);
mailClient.Disconnect(false);
}
Appreciate your feedback in this regard.
The Dispose() method will only close the socket connection if it is still alive (which is effectively the same as calling Disconnect (false)).
Calling Disconnect (true) is much more courteous, though, as it sends the appropriate LOGOUT or QUIT command to the server which allows the server to properly dispose of their resources.
Related
For some client side procedures, I implement remote logging to log the calling of the procedure. The log is printed several times with different thread id, even though the procedure is only called once. Some rpc requests are sent to the sever a few times which causes some database session problem. Is it normal? Is there anyway to avoid it?
Thanks
This is not normal, and suggests there is a bug on your client causing it to send the same call more than once. Try adding logging on the client where you invoke the RPC call, and possibly add breakpoints to confirm why it is being called twice.
My best guess with no other information would be that you have more than one event handler wired up to the same button, or something like that.
--
More specifically, your servlet container starts multiple threads to handle incoming requests - if two requests come in close succession, they might be handled by different threads.
As you noted, this can cause problems with a database, where two simultaneous calls could be made to change the same data, especially if you have some checks to ensure that a servlet call cannot accidentally overwrite some newer data. This is almost certainly a bug in your client code, and debugging it should start there.
I implemented an UWP Server Socket following the sample here and it correctly works.
Now I want to make the app able to continuously accept requests, but I expect that when the app is suspendeded and a client sends a request, the server is not able to respond. If I am correct, what is the best way to avoid this status change? If possible, I would prefer a solution with Extended Execution instead of implementing a Background Task, but I don't know if the following code in the OnSuspending method is enough to keep the app in the Running status:
var newSession = new ExtendedExecutionSession();
newSession.Reason = ExtendedExecutionReason.Unspecified;
newSession.Revoked += SessionRevoked;
I saw people calling a "LongRunningWork()" function in other samples, but in my case the code to execute is already defined in the code-behind of the view as shown in the link above, so I would like simply keeping the app always running. Keep in mind that it is a LOB application, so I don't have Store limits.
Is it possible to create a proxy object in the client code without using any request context?
I want this behavior because I want to send the object to the server multiple times and I cant do so if its associated to single request context.
You can create your proxy with one RequestContext and send it. Once the response is received, the object is frozen and no longer attached to a RequestContext, you can thus send it with another RequestContext (as before, you'll have to wait for the response before being able to use it yet another RequestContext).
I'll investigate if these constraints can be relaxed in a future version of GWT.
I just got asked to reduce the traffic made by my GWT app. There is one method that checks for status.
This method is an asynchronous call wrapped in a Timer. I know web apps are stateless and all that, but I do wonder if there is some other way to do this, or if everyone has a Timer wrapped around a call when they need this kind of behaviour.
You can check out gwteventservice. It claims to have a way to push server events and notify the client.
I have a feeling they might be implemented as long running (hanging) client to server RPC calls which time out after an interval (say 20sec), and then are re-made. The server returns the callback if an event happens in the meanwhile.
I haven't used it personally but know of people using it to push events to the client. Have a look at the docs . If my assumption is correct, the idea is to send an RPC call to the server which does not return (hangs). If an event happens on the server, the server responds and that RPC call returns with the event. If there is no event, the call will time out in 20 seconds. Then a new call is made to the server which hangs in the same way until there is an event.
What this achieves is that it reduces the number of calls to the server to either one for each event (if there is one), or a call once every 20 seconds (if there isn't one). It looks like the 20 sec interval can be configured.
I imagine that if there is no event the amount of data sent back will be minimal - it might be possible to cancel the callback entirely, or have it fail without data transfer, but I don't really know.
Here is another resource on ServerPush - which is likely what's implemented by gwteventservice.
Running on Google app engine you could use they Channel technology
http://code.google.com/intl/en-US/appengine/docs/java/channel/overview.html
If you need the client to get the status from the server, then you pretty much have to make a call to the server to get it's status.
You could look at reducing the size of some of your messages
You could wind back the timer so the status call goes out less often
You could "optimise" so that the timer gets reset when some other client/server IO happens (i.e. if the server replies you know it is ok, so you don't need to send the next status request).
If I have a client app sending requests to my web service, one after another, will the web service be able to handle each request made and not override previous request because of a new request made? I want all requests to be handled and not replaced for another. Will I be able to do this with the multiple requests all coming from the same client
I have no idea why the other answer is so long to what is essentially a simple question about the basics but the answer is yes.
Each request is independent of others, unless you specifically program some sort of crossover into the server (e.g. a static cross-thread list used by every request or a more complex structure).
It is easier to encounter crossover on the client side, if using an asynchronous pattern that gives results via events - you need to make sure you got the result to the correct request (generally done by providing some token as the "custom state" variable, which you can use to determine the original request in the response handler).
The answer depends on your architecture.
For example, if the server is multi-threaded, and the business logic part is stateless, then on the server the requests won't override, as each thread will call a function and return the result.
On the client side, your best bet is to have each request sent from a different thread, so that that thread blocks until it gets its response, then the processing can go on fine.
If you have a different design, please describe it.
UPDATE: Based on the new info here is something you may want to look at:
http://weblogs.java.net/blog/2006/02/01/can-i-call-you-back-asynchronous-web-services
I am curious how, or if, you are doing asynchronous webservice calls. Generally webservices seem to block, but if you are making these calls so fast then I can only assume asynchronicity.
So, the webservice can store the answers on the server-side, so there is a stateful class that stores results in a dictionary, by IP address. The client then polls for answers, so, ideally, if you send a request, you should be able to get back an array of answers as a response. If you have sent all the requests and are still waiting for more responses, then poll. You should be able, again, to get an array of answers, to cut down on wasted bandwidth.
The better approach is to have your client also be a server, so that you send the request, with the IP address:port for the callback, so the server would make a oneway response to the client. But, this is more complicated, but it cuts down on wasting bandwidth.
Update 2: This is being done without checking it, so there is probably errors:
#WebMethod
public ResponseModel[] AnswerQuestion(QuestionModel[] question) {
// Get the IP address of the client
AnswerController ac = new AnswerController(question, ipaddress);
return mypackage.myclass.StaticAnswers.GetAnswers(ipaddress);
// return an array
}
#WebMethod
public ResponseModel[] GetAnswers() {
return mypackage.myclass.StaticAnswers.GetAnswers(ipaddress);
}
OK, this should give a rough idea.
There is no assumptions in AnswerController. It should know everything it needs to do the job, as it will be stateless, so, it refers to no global variables that can change, only const and perhaps static variables.
The StaticAnswers class is static and just stores answers, with the lookup being ipaddress, for speed.
It will return the answers in an appropriate array.
When you have sent the last question then just call GetAnswers until you have gotten back everything. You may need to keep track of how many have been sent, and how many have been received, on the client side.
This isn't ideal, and is a very rough sketch, but hopefully it will give you something to work with.