Jamama Design

Essential Objects

Jamama Object/Instance (aka a Configurable)

Objects that are directly configurable through JMX are Configurable. This includes Directors (normally only one), Routers, Repositories and ThirdPartyConfiguroros. These are instantiated by virtue of having a block under <instances> in the Jamama configuration file. (When we implement it, you will be able to create new instances with JMX also).

Repository

A generic data getter/fetcher/remover interface to a storage receptacle backend like a DB or a FS branch. A Repository must be able to handle the type of object that you need to persist, and there may be multiple repositories that can persist a particular object type. Each Repository may implement the ability to manage multiple storage objects, so that one Repository could store the same object to different files or to different mailboxes.

item Mit = Message-In-Transit.

Corresponds to elements in a Sendmail "mailq". Message in mail system which has not reached its final destination (i.e., not delivered to a local mailbox or a remote system or dropped).

Director (Initiates all routing)

This is the only object that "initiates" non-ping routing for a Mit. (A Router may reroute a Mit, but that is nonetheless a Mit in-process; to route ANOTHER Mit, a Router must persist a new Mit (and Server will thereafter pick it up). Periodically runs routingRun(null, Mit.STATE_RUNNOW, false) and routingRun(null, Mit.STATE_DEFERRED, false). This attempts to route all Mits that are ready to go.

Pipeline

Sequenced list of Routers. If every configured Router in were to return STATUS_CONTINUE, they Routers would each be accessed in this order and finally the default routing method in Director, which will abort the Mit.

Jamama

The main Jamama process, Jamama is a JMX Agent. The Director thread (above) is the main thread, and may have subthreads. Jamama also starts up other Servers, each in its own thread, (and they may also have subthreads).

Router

Filtering AND Mit consumption abilities. A Mit is "routed" through a chain of Routers.

Server

Servers must expose the "run" attribute, i.e., setRun(bool) and getRun(). This will typically be accomplished by implenting Runnable and by invoking (thread.start(this)) for setRun(true). These threads typically generate mits like

    Director.createMit().persist(false)

It may have sub-threads, of course.

A Server may also be a Router. (E.g., SMTPServer is primarily a Mit Generator that listens on smtp port in order to create Mits, but it's route() method is also called by Mits running in the same thread-- and only succeeds if the current thread is connected to that host in ETRN mode).

FAILURE/RETRY info

The best place to store failure information is in the object CAUSING the problem. Like in the UnavailableHostCache, not in the message itself. The next time routingRun() is run, all Mits waiting for that host will go.

SMTPCaching

• Keeps per-host status info. It needs to be shared among all Internet Routers.

• Operation: update(domain,ip) Update SMTPCache records for host and/or domain. Call

SMTP RECEPTION

    MAIL FROM:
        mit = Director.createMit();
        mit.state = STATE_INCIPIENT;
        try {
            Director.headPipe.route(mit, true, null);
        } catch (Exception e) {
            Send error status to client.
            mit = null;
            return;
        }
    for each (RCPT TO:) {
        try {
            Director.headPipe.route(mit, true, null);
        } catch (Exception e) {
            Tell client that this recipient not allowed.
        }
    }
    DATA: (? skip this ?)
        try {
            Director.headPipe.route(mit, true, null);
        } catch (Exception e) {
            Send error status to client.
            mit = null;
            return;
        }
    mit.state = Mit.STATE_ROUTENOW
    mit.persist(false);
    // MIT will send it as soon as it can.  Don't want to make the
    // client wait for us after we have persisted it.

SMTP

• BULK TRANSMITS done by 1-level recursion, not by multithreading. (I think no need to check for recurse since there is no way to recurse other than 1 level in our recursion one case.

• This incurs no multi-threading, although we have to deal with the existing multithreading in SMTPSession).

OUTGOING SMTPConsumer

• Always SMTPCaching.update(domain,ip) after every successful or failed conn.

• Don't use the Incoming server for outgoing unless client ran ETRN.

• It would be nice to use JavaMail, but I don't know if that supports bulk xmits. If not, could still use JavaMail for prototyping the SMTPSharedConsumer.

• After first successful xmit to this domain, run

      Director.routingRun("nextPipe == " + mypipe
       + "destdomain == '" + destdomain + "'");
      If there are more Mits for this target ipaddr, then this
           router() method will be called recursively.
       ++recursecount;
       try {
          if (recursecount > 1) {
              if (state != STATE.GREETED) throw... // assertion
              piggyback(mit);
              return;
          }
      } finally { --recursecount; }
      piggyback(mit) {
          out.println(mit.this...
          flush();
          return;
      }

INCOMING SMTPServer

• • Always SMTPCaching.update(domain,ip) after every successful or failed conn.

  • Need to maintain a ETRN mode HashMap of currentThread X session.

  • When a SMTPSession gets an ETRN, it can run

            Director.routingRun("nextPipe == " + myPipe
             + ip == '" + ipaddr + "'");
        SMTPServer.route(Mit mit, boolean ping) {
            if (ping == true) return;
            session = (SMTPSession) etrnSessions.get(Thread.currentThread());
            session.piggyback(mit);  // Same as in SMTPSession
            return;
        }