I have a constantly-running Java program that needs to send an email whenever it encounters a problem. However it is possible that the mail server it uses could be down at the time it tries to send the email.
What is the best way to ensure that the email will be delivered when the mail server comes back up?
Queue up the requests. Have a separate thread which merely waits for something to enter the queue, then tries to email it. If it fails, it waits a few hours and tries again. Once it sends a message, it goes back to the queue to get the next message.
Put the email object into a stack or list when it fails to send, when the email server comes back up, pop each email out until it is empty.
You may want to save the email in a file, perhaps an xml file, so that should the application crash you won't lose this information.
This file is loaded when the application starts, and it keeps everything in memory, so that while there are pending emails then it keeps checking every 5 minutes or so, then, as it sends each email it will resave the xml file, so that should it crash after sending 3 emails out of 10 it won't resend those three when it starts up.
But, how you handle that is really going to depend on the specification for how to handle error conditions.
If you go from "forward everything to this SMTP server which is always there" to a situation where you need to handle all kinds of conditions normally handled by a full SMTP-server like retry later, retransmit if connection closed, use MX-hosts in their stated order and similar, you may want to consider simply having a SMTP-server inside your client (but one that does not accept incoming connections) since this moves all the dirty logic away from your applications.
I believe that the James email server - http://james.apache.org/ - is easily embeddable, but I have not actually tried.
The suggestion of using James is a good one but I've had some issues in the past of James being a bit flaky and needing to be restarted.
You could use something like Quartz to have a scheduler check for messages that need to be sent. If the message can't be sent (eg. smtp server isn't available), then that message is rescheduled to be sent at a later time. You could either have a task per message or have a persistent task that checks for messages and available mail server then sends the messages. The persistent task would give you email batching.
If you are in a Unix/Linux world, then consider the alternative of sending your alerts using syslog, and dealing with the generation of emails on that side. For example, nsyslogd has a module called ommail for generating emails natively.
IIRC, there are adapters for log4j and the like that can bridge between the Java and syslog worlds with a minimum of (zero ?) coding.
Apache James - http://james.apache.org/ will let you run your own mailserver as a proxy, not only that but is written in 100% java, so you can figure out what its doing,
and as an extra bonus James uses databases to queue the mail, so you can even inject mail directly into the queues by inserting into a database, then leave whole business of sending the mail up to James.
Related
I am trying to send Skype messages with skype-java-api. All messages sent in this way are staying in sending state and never actually getting sent. I can see the messages but all are with loading logo beside them. However, when I sent message normally from Skype, it is getting sent.
I believe the "skype-java-api" is reaching (or has) it's end of life.
From the github page
Important: Desktop API is crippled now
As time passes, this project becomes less and less relevant due to
Desktop API discontinuation.
and even more important
According with issue #81, the chat support already stopped working.
It appears that this is what you encountered.
I have a web-service on my server that pushes the xml data to the clients that are communicating to it over internet.
In these cases we have challenge to receive acknowledgement from the
client.
Specific case like, once client has received the data and before
sending the acknowledge, if the communication channel goes down.
Example:
In case of the software updates on clients over internet, how the server makes sure every thing is processed fine.
If you want to go on the "push" path, and you absolutely must know if the update was succesful, then you have to build your service and clients in such a way that you do know.
Basically what you need to do is build a small protocol so that information is transmitted no matter the failures of the communication channel. This means two things:
Your service does re-transmissions;
Your clients can deal with duplicate messages;
For example:
service pushes a message, client acknowledges => all good;
service pushes a message, the connection goes down, the message is lost. The client does not acknowledge since it never got the message => service pushes that same message once again at some later time. Now hopefully you get to case 1.
service pushes a message, client acknowledges but the connection fails and the service does not receive the acknowledge => similar to 2, so the service pushes that same message once again some later time and now the client receives the same message twice. It must ignore the second message but still needs to send an acknowledge so the service does not send it a third, forth, ... nth time;
And so on and so forth...
This is a high level description of what TCP does, for example. TCP is a reliable protocol over an unreliable network. It handles dropped packets, duplicated packets, etc.
Now, that would be pushing. A more simple alternative would be to use "pull" instead. The clients periodically pull the updates from the server. This is simpler to implement (the download is succesful if it worked, otherwise you try again later) but it's not without its gotchas, like for example:
controlling when clients start to pull data from the service. You can't just have them all update at the same time or you might overload the server. Clients should first ask the server if it's OK to update now or comme back later when the service is not so busy;
are you downloading upgrades in the background, from user devices? Data charges might apply so maybe it's better to ask the user if it wants the update now or later instead of doing it behind the scenes;
updating in the background, even if there is no problem with data charges might still consume bandwith when the client needs that bandwith for something else;
And so on and so forth...
The thing is this is a large topic, with general solutions that might not apply given particular situations. But it is not a new topic. Others have had these issues before. Consider for example Windows updates, how each PC's OS updates itself. Something similar happened a while ago when thick clients needed updates. The world moved to thin clients but now thick clients are making a comeback. Have a look at how these issues are solved, you will find usefull information online.
I do not think there is a way to do that. I believe the reason you are asking is for the following reasons:
1) If you are asking because you are sending a lot of data and your client deny receiving it, perhaps you can paginate it. That way you will know when the last page was accessed. You can even go one step further and just put very little data on your last page, that way you are sure that the last page is called.
2) If you are genuinely concerned about ensuring that they receive the entire data. How about suggest they access a 2nd web service which contains the checksum for the data, and suggest that they compare it.
Assuming that your web service is RESTful, your server should be stateless. The client should make sure it receives the data properly.
You could define a service to get the hash value of the data, followed by the request to receive the data itself. The client can check after the download whether the hash value of the downloaded data corresponds to the value received by the first call.
Amongst others, you could use MD5, SHA-1 and SHA256 in standard Java, as described in the Oracle documentation. This will calculate the hash value of the data from the server side.
Assuming you use Javascript from the client side, there are many possibilities to calculate the hash code using the same algorithms (jsSHA, for example).
I hope it helps.
I currently am developing a semi-simple chat app. I want the user to be able to communicate with one other person in a private chat. Just plain text will be sent. Currently my system calls php scripts from a webpage, passes in parameters and then parses the data returned. I have it so that the client sends the message, which calls a send message script on my webserver, the script then makes a message file on the webserver and then returns a success or failure back to the client. Then for the client to view this message, it would have to call a script that checks the server for a message file with a message for him. If it finds one, it sends the message back, if not, it sends a response about not having messages.
This technique works perfectly besides the fact that the client either would have to manually refresh to check to see if he had messages, or a background thread would have to refresh every few seconds. That would be fine, however that would use data if the user was on a mobile network. Not to mention the kind of resources a background loop would pull if it was refreshing at a speed that would be convenient.
So, I decided on a second idea, this would be a server programmed in Java, which would communicate over sockets. The user would send the message as a packet over the socket and the server would check to see who it was meant to go to. If the person is online, it passes the message along to that user. However this method requires a constant connection between the client and the server and that is unreliable because what if the user is in the car and data cuts out. Or some other situation where the connection gets severed. Then it would throw errors and have to reconnect.
Anyhow, my question is which technique is better. Or are they both terrible? If so, what is the correct way of doing this? Thanks in advance.
AngularJs and Ajax will be the perfect solution for you , try to learn
for actually real time messaging Use AngularJs
If the amount of data is very less ..say 20-25 messages per day...you can REST APIs on your server to transfer actual text messages and Google Cloud messaging for pushing notifications..Recently I followed this approach to develop private chat for one of my friend.
We are developing a webapp that needs to send out emails written in Java/Groovy. Currently, we are persisting each email to a database before we call the Java Mail APIs to send the mail to our SMTP server.
I want to send out email asynchronously. I want to persist the email and then have another process pick up the email and send it (and send it only once). Ideally, this process is running outside of my webapp.
Are there any tools that do that?
Update: This solution needs to prevent duplicate emails and it needs to handle spikes in email. I was hoping someone already wrote an offline email processor. (I'd rather not implement this myself.)
The suggestions to use a cron job to read the database are quite workable.
Another good approach here is to use a Java Message Service (JMS) message queue. These are persistent (backed up by a database) and reliable. You can have one or more producer programs enqueue messages with the relevant data in them, and then one or more consumers process the messages and dequeue them. All of this is set up for very high reliability, and you gain the flexibility of asynchronously decoupling the operations, which means during email spikes the message queue can grow larger until the consumers catch up with the spike. Another benefit is that the email goes out as soon as a consumer gets to it instead of on a timer. Plus, if you require high availability, you can have multiple consumers in case one goes down.
Check out Apache's ActiveMQ for a good open source implementation of JMS.
If you're using Linux/Unix you could create a cron job to run every few minutes which calls a program to grab the email from the database and send it out. You could also have a field in the database to indicate whether the message has been sent. The downside of this approach is that there may be a delay of a few minutes from when your webapp persists the email and when the cron job is run.
Setup a cron job and use scripts to query the db and send out emails via sendmail.
On the off chance it's an Oracle DB, you can use the UTL_MAIL package to write PL/SQL to send the mail through your SMTP server. Then create a scheduled job to execute on your desired schedule.
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/u_mail.htm
Since you are already using groovy, this might be an interesting tool to solve your problem
http://gaq.sourceforge.net/
You could use Quartz, a scheduling library (similar to cron), to schedule a recurring task that reads the DB and sends the emails. If you're using Grails, there's a Quartz plugin that makes working with Quartz a bit more Groovy.
I have a school project in which I have to implement a chat application, whose server will be a java web service.
The problem is that I've always thought of a web service as a way of calling remote functions, and I have no idea how to keep a "session" active on the web service, nor how to keep track of all the people currently in chat, rooms etc.
To the best of my knowledge, a chat server is supposed to know its clients after an initial connection, and send every client message to all clients. This definitely calls for some sort of session maintenance. I think the right way to do this is as follows:
Client calls web service 'handshake' and provides some minimal identification details.
Server returns an acknowledgment that includes a unique client identifier.
Client calls web service 'message' and sends a new message, together with its identifier.
Server identifies client by the identifier, distributes message to all clients.
I'm not really sure how the message distribution should work, as web services are essentially a pull-service and not push. Perhaps the client should expose its own web service for the server to call.
Hope this helps,
Yuval =8-)
You could consider implementing a COMET solution. This will effectively give you push communication, thus eliminating latency, a VERY nice feature for a chat application.
If you want to go for the gold, consider implementing more advanced features:
spell check
URLs/email addresses converted to links automatically
separate chat rooms
moderator functions (terminate chat, kick user)
event info like "User is typing..."
statuses (available, busy, away...)
avatars
...
I don't know Java so this answer will be language agnostic.
In my opinion the simplest way to do this without running a process on the server would be to store all your data in a database.
Here is a short list of the basic things that will need to be done:
Need a table with a list of users and passwords for authentication
Need a table for the currently logged in uses
A. needs a time stamp field of the last contact
When a users does something update the last contact field to the current time
If the user' last contact time is > current time + 2 minutes then they are logged out
client side application will need to send periodic messages to the server to say "Im still here"
You'll need to find a way to determine when a message has been sent and when to update the client's display that a message has been received, this I will leave to you.
If you still need some help here is an AJAX/ASP.Net chat app that should (I didn't look at its source) work much the same way.
I wrote a chat engine which had a service in the background and everything stored in a database, an input form frame and an output frame which received the html stream.
If you want to skip the service part and only implement via a web service, you need to implement at least two operations: Post for inputs, and GetLatestChanges to receive the chat's output, which translates into HTML using some Javascript magic.
Of course you need to keep track of rooms, users, messages, which user receives which texts etc, as sketched by Unknwntech.