Undelivered Mail Returned to Sender

This is the Postfix program at host caucho.com.

I'm sorry to have to inform you that your message could not be
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                        The Postfix program

<baoogle@xxx.com> (expanded from <hessian-interest-mailout>): host
    mx.126.split.netease.com[202.108.5.166] said: 550 User suspended (in reply
    to RCPT TO command)

<xml_resin@xxx.com> (expanded from <hessian-interest-mailout>): host
    mx.mail.163.split.netease.com[202.108.5.116] said: 550 Invalid User:
    xml_resin@xxx.com (in reply to RCPT TO command)

<jasons@xxx.net> (expanded from <hessian-interest-mailout>): host
    baracuda.aebn.net[216.54.226.49] said: 550 <jasons@xxx.net>: Recipient
    address rejected: No such user (jasons@xxx.net) (in reply to RCPT TO
    command)

<Mattias.Arbin@xxx.se> (expanded from <hessian-interest-mailout>): host
    mail.carmenta.se[213.115.187.2] said: 550 5.2.1
    <Mattias.Arbin@xxx.se>... Mailbox disabled for this recipient (in
    reply to RCPT TO command)

<yingshou.guo@xxx.com> (expanded from <hessian-interest-mailout>): host
    mail.efriendsnet.com[59.151.17.229] said: 511 sorry, no mailbox here by
    that name (#5.1.1 - chkuser) (in reply to RCPT TO command)

<albert@xxx.com.hk> (expanded from <hessian-interest-mailout>): host
    mail.gandanet.com.hk[64.14.72.38] said: 511 sorry, no mailbox here by that
    name (#5.1.1 - chkuser) (in reply to RCPT TO command)

<drew@xxx.com> (expanded from <hessian-interest-mailout>): host
    smtp.secureserver.net[64.202.166.12] said: 554 The message was rejected
    because it contains prohibited virus or spam content (in reply to end of
    DATA command)

attached mail follows:

Scott Ferguson wrote:
>
> On Jun 22, 2006, at 5:04 PM, Tom Kaitchuck wrote:
>
>> Hello all,
>> I have been working on adapting hessian for a project I am working on. I
>> have already created a modified version of com.caucho.hessian.io which
>> has performance enhancements, code cleanup, feature removal, and a
>> number of unit tests. I plan to continue to make improvements, but have
>> no intention of providing any support. If anyone would find this useful,
>> just let me know where to send the diff.
>
> Interesting. What performance enhancements did you find?
The major ones are:
In hessianInput there are sever sections of code that look like this:

      _chunkLength = (read() << 8) + read();
      ByteArrayOutputStream bos = new ByteArrayOutputStream();

      int data;
      while ((data = parseByte()) >= 0)
        bos.write(data);
      return bos.toByteArray();

However it is better to do:

      _chunkLength = (read () << 8) + read ();

      byte[] result = new byte[_chunkLength];
      _is.read(result);
      return result;

And in MapSerializer there is a section that looks like:

    Iterator iter = map.keySet().iterator();
    while (iter.hasNext()) {
      Object key = iter.next();
      out.writeObject(key);
      Object value = map.get(key);
      out.writeObject(value);
    }

But is better to do:

    Iterator < Map.Entry > iter = map.entrySet ().iterator ();
    while (iter.hasNext ()) {
       Map.Entry entry = iter.next ();
       out.writeObject (entry.getKey ());
       out.writeObject (entry.getValue ());
    }

>> I noticed that you have added some new types in the draft for Hessian
>> 2.0, but it is not clear from the WIKI what each of these values
>> actually represents.
>
> I added a new page at http://wiki.caucho.com/Hessian_2.0 to describe
> some of the draft ideas.
>
>> I would also like to specifically request that if
>> the comment period is not closed c/c++ primitives be supported, as I
>> will need to implement this anyway, and I would prefer not to break
>> compatibility.
>
> We just started brainstorming for Hessian 2.0. I'm guessing it will
> be at least 6 months before we make it final. No sense rushing in it.
>
> The goal is not to add any new types, merely compact representations.
>
> c/c++ primitives should already be supported, just in a somewhat
> wasteful manner, since you can encode a byte using I x x x x.
I was thinking more along the lines of supporting both *signed and
unsigned *versions of:
byte, short, int, long, long long, float, double and quad. The point of
signed vs unsigned is not that you could not encode the same data some
other way, but that a client should be able to query whether something
was sent as a signed or unsigned integer. Of course if the client calls
a hypothetical function getSignedInt(), they should get it is a signed
integer, regardless of what type it is in the datagram.