requesting addition to ByteCodec class

Hi,

Minor knit.  I would like to use the ByteCodec.encode method on a 
sub-array.  It would be good if an encode method taking offset and 
length where present in the ByteCodec class.  The alternative is to copy 
the subarray to encode into a new array, which is not efficient.

Here are the diffs.

Index: org/jabberstudio/jso/util/ByteCodec.java
===================================================================
RCS file: /home/cvs/jso/src/org/jabberstudio/jso/util/ByteCodec.java,v
retrieving revision 1.5
diff -r1.5 ByteCodec.java
52a53,54
 > 	 *  <at> param offset index of first array element to convert.
 > 	 *  <at> param len number of bytes to convert
56c58
<         public String encode(byte[] input) {
---
 >         public String encode(byte[] input, int offset, int len) {
61a64,67
 >
 > 	    len += offset;
 >             if (len > input.length)
 >                 len = input.length;
63c69
<             for (idx = 0; idx < input.length; idx++) {
---

Handling partial writes

AbstractStream assumes that when it calls StreamSource#write, everything 
gets written.  The return value of write (number of bytes actually 
written) is not checked, unwritten bytes are never written.

         public void sendPacket(Packet p) throws IOException {
             StreamContext   ctx = AbstractStream.this.getOutboundContext();
             String          buffer = " ";
             String          charset = ctx.obtainCharset().name();
             byte[]          output;

             if (p != null) {
                 _Exporter.getContext().add(p);
                 buffer = _Exporter.write(p);
                 _Exporter.getContext().remove(p);
             }

             output = buffer.getBytes(charset);
             _Writer.write(output, 0, output.length);

             if (p != null) {
                 AbstractStream.this.getOutboundQueue().add(p);
             }
         }

This can lead to corruption of XML stream.

I thought of fixing this in AbstractStream, but realized that it would 
be quite unsettling.  Assuming AbstractStream were able to beffer data 
to be written, we'd need a public mechanism to trigger a write attempt 

Monitor fixes

Hi,
I have few fixes to the Monitor class.
1. Creates the Timer as a daemon, so that the
application can exit when it has done all of its work.
2. Avoids the race condition between send() and timer
scheduling.

Below are the diffs
Thanks,
Vijay.

Index: org/jabberstudio/jso/util/Monitor.java
===================================================================
RCS file:
/home/cvs/jso/src/org/jabberstudio/jso/util/Monitor.java,v
retrieving revision 1.7
diff -r1.7 Monitor.java
446c446
<             _DefaultTimer = new Timer();
---
>             _DefaultTimer = new Timer(true);
712d711
<         match.send(p);
713a713
>         match.send(p);
819c819
< }
\ No newline at end of file
---
> }

DattaFactory changes

Hi,
net.outer_planes implementation of Stream is a
DataFactoy  by itself, Since AbstractStream extends
from DataFactory.  
Since DataFactory data remians the same most of the
time,  we can optimize memory by sharing the base set
of Registered elements and namespace mappings.

if we do create lot of streams in the same JVM, then
it certainly saves lot of memory.

I have modified the Datafactory to hold a reference to
a base datafactory, which is readonly. If a specific
stream adds new elements or namespaces, new
datastructures are created appropriately.

Below are the diffs. These diffs are against 0.13.2
version

DataFactory diff
---------------
15a16
> import java.util.Collections;
50,51c51,53
<     private Map     _Registered = new
java.util.TreeMap(NSI.STRICT_COMPARATOR);
<     private Map     _NamespaceMappings = new
java.util.TreeMap();
---
>     private DataFactory _baseDataFactory = null;

DataFactory changes for Performance improvement

Hi,
Better formatted diffs as attachment.

net.outer_planes implementation of Stream is a
DataFactoy  by itself, Since AbstractStream extends
from DataFactory.  
Since DataFactory data remains the same most of the
time,  we can optimize memory by sharing the base set
of Registered elements and namespace mappings.

if we do create lot of streams in the same JVM, then
it certainly saves lot of memory.

I have modified the Datafactory to hold a reference to
a base datafactory, which is readonly. If a specific
stream adds new elements or namespaces, new
datastructures are created appropriately.

Attached the diffs. These diffs are against 0.13.2
version

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

DataFactory diff
---------------
15a16
> import java.util.Collections;

Recent Patches

Thank you all for the recent spate of patches. I'm fine with all of them 
so far, and will get them incorporated into JSO soon (hopefully, EOD today).

If you can, though, please send the diffs as attachments. It makes them 
a little easier to get applied.

Thanks,

--

-- 
-  LW

GOT JABBER™? <http://www.jabber.org/>

Re: Handling partial writes

Actually, I feel better about making the change to ChannelStreamSource 
than adding a "trigger pending writes" method. Almost exclusively, 
people expect a write to dump everything.

Thanks for the catch. I'll get this in place soon.

- LW

Jacques Belissent wrote:

>
>
> AbstractStream assumes that when it calls StreamSource#write, 
> everything gets written. The return value of write (number of bytes 
> actually written) is not checked, unwritten bytes are never written.

--

-- 
-  LW

GOT JABBER™? <http://www.jabber.org/>

Re: Recent Patches

Here is the attached diffs
Thanks
Vijay

--- "Matthew A. Miller" <linuxwolf <at> outer-planes.net>
wrote:

> Thank you all for the recent spate of patches. I'm
> fine with all of them 
> so far, and will get them incorporated into JSO soon
> (hopefully, EOD today).
> 
> If you can, though, please send the diffs as
> attachments. It makes them 
> a little easier to get applied.
> 
> 
> Thanks,
> 
> -- 
> -  LW
> 
> GOT JABBER™? <http://www.jabber.org/>
> 
> _______________________________________________
> jso-devel mailing list
> jso-devel <at> jabberstudio.org
> http://mail.jabber.org/mailman/listinfo/jso-devel
> 

request for non blocking Stream open and close

Stream#open sends the outbound stream opener and waits for the inbound 
stream opener.  Similarly Stream#close waits for the inbound closing 
stream tag.  Instead of waiting for a packet coming from the remote end, 
it is sometimes more efficient to return right away and continue the 
processing when the expected StreamStatusListener#statusChanged callback 
is invoked.  This also requires that timeouts be handled otherwise.  In 
order to make this an option, I would like to suggest the following:
   1. expose openOutbound as a public method
   2. add a closeOutbound method

There is another issue addressed by the attached diffs:  When multiple 
packets are received in a short amount of time, we noticed that JSO 
parses them all in, and then invokes the packet listeners for all.  Any 
reason why it does that?  We found it preferable to process each packet 
after it is parsed.  This helps in making sure that we don't take in 
more than we can process.

Jacques

Index: AbstractStream.java
===================================================================
RCS file: /home/cvs/jso/src/net/outer_planes/jso/AbstractStream.java,v
retrieving revision 1.44
diff -r1.44 AbstractStream.java
104a105
> 		    firePacketTransferredEvent(PacketEvent.RECEIVED);
833c834
<     protected void openOutbound() throws StreamException {

XMLWriter perf improvements

Hi,
Have done few performance enhancements in
encodeTextValue() and encodeAttributeValue().
Basically avoid creation of new StringBuffer objects
unless it is absolutely required.

Few enhancements to visit(), so that multiple calls to
getNamespacePrefix() and getNamespaceURI() are
avoided. Also parts of generateQName() is written
inline inside visit() to avoid function call overhead
and object creation.

Did test this for a roster packet. Packet.toString() 1
millon times is 22% faster than earlier version

Attached are the diffs.

Thanks,
Vijay

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250

_______________________________________________
jso-devel mailing list
jso-devel <at> jabberstudio.org