I have a server that uses sockets to connect with clients. These connections are not persistent. The typical usage pattern is to submit 'work' to the server. It receives the job, checks as best as it can that it can actually satisfy requirements, notifies the user, and then disconnects the client. The workload can be queued behind an arbitrary number of tasks, so the time the server starts to perform a specific job is not easily predictable. When it goes to perform a task it could encounter an error.
My question is: How can I let a user know information about the error it receives? In my case, jobs typically create their own work area where they produce results on a shared filesystem. I can, and do, report errors here. However, a certain class of errors can occur before an appropriate directory structure is created. If I can't place them into a file under this structure how will I report them?
Some of my ideas:
1) Allow the client to retrieve job results through a separate communication with the server. This will require the server to record the status of failed workloads. I could start consuming memory pretty quickly if I keep this data around for too long. I supposed I could store the results in a file in a general location and retrieve on demand.
2) Require that each client have a pre-defined workspace prior to submitting the job. The server will require that this directory exist and be writable before it will accept jobs.
3) Email every failure. However, this doesn't appear too attractive to me. A tool which creates automated dispatches might make the same error on a large number of jobs. When the user goes to read email -- disaster!
Anyways, do any of these solutions seem reasonable? What other ways might I consider?