headers
Matthew A. Miller | 4 Feb 2004 15:33
Gravatar

Re: JEP0045(Multi User Chat) support

Sorry for the late response.

I don't know of any StreamElement interfaces for MUC.  I think it would 
be great to have these.  I'm focusing more on core XMPP compliance 
(SASL, TLS), and  binary data transports  (IBB aka JEP-0047, S5B aka 
JEP-0065).  I would like to have those ready for the 0.12 release.

If you'd like them to be part of the JSO distribution, just drop me a 
private e-mail, and we'll work out the details.  If you need one, 
there's a guide for implementing custom StreamElements in JSO, located 
at 
http://www.jabberstudio.org/~linuxwolf/jso-0.11-DEV/doc/custom-elements.html.

Thanks,

-  LW

Rahul Shah wrote:

> Hi,
>  I was just wondering if anyone is working on implementing JEP 
> 0045(Multi User Chat). If no one is implementing it then probably I 
> can give a try at it.
>
> -Rahul
>
> _______________________________________________
> jso-devel mailing list
> jso-devel <at> jabberstudio.org
> https://jabberstudio.org/mailman/listinfo/jso-devel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacques Belissent | 10 Feb 2004 04:30
Picon

stack overflow in AbstractStream#close


Hi,

in AbstractStream, close calls process which calls close if there is an 
exception when processing input.  and so on.

I may be doing something wrong, but I think the API ought to catch this. 
  Perhaps close should return silently if there is already a close in 
progress.

(i have put some instrumentation in the code, so line numbers may be 
approximative).

java.lang.Throwable
         at 
net.outer_planes.jso.AbstractStream$Input.process(AbstractStream.java:143)
         at 
net.outer_planes.jso.AbstractStream.process(AbstractStream.java:952)
         at 
net.outer_planes.jso.AbstractStream.close(AbstractStream.java:854)
         at 
net.outer_planes.jso.AbstractStream.process(AbstractStream.java:983)
         at 
net.outer_planes.jso.AbstractStream.close(AbstractStream.java:854)
         at 
net.outer_planes.jso.AbstractStream.process(AbstractStream.java:983)
         at 
net.outer_planes.jso.AbstractStream.close(AbstractStream.java:854)
         at 
net.outer_planes.jso.AbstractStream.process(AbstractStream.java:983)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jacques Belissent | 10 Feb 2004 06:47
Picon

tight loop in AbstractStream#openInbound


Hi,

Using my own StreamSource implementation, i noticed that it was asked to 
read non-existent new data an inordinate amount of times during the 
stream opening phase.  I traced it down to a tight loop in openInbound.

I tried to work around the problem by using a condition variable which 
gets triggered when the inbound status changes.  I said "tried" because 
it does not quite always work.  I still do not understand why sometimes 
the status never changes.

Here is the code I'm referring to.

     protected void openInbound() throws StreamException {

-->        while (getInboundStatus().isConnected() &&
-->               !getInboundStatus().isOpened()) {
-->            process();

         if (getInboundStatus().isDisconnected())
             throw new 
StreamException(getDataFactory().createStreamError(StreamError.REMOTE_CONNECTION_FAILED_CONDITION));
     }

Jacques
Permalink | Reply | 0 comments |
headers
Matthew A. Miller | 10 Feb 2004 13:01
Gravatar

Re: stack overflow in AbstractStream#close

We probably found the problem at about the same time.  The codebase in 
CVS should already address this.  Please let me know if it is still a 
problem.

-  LW

Jacques Belissent wrote:

>
> Hi,
>
> in AbstractStream, close calls process which calls close if there is 
> an exception when processing input.  and so on.
>
> I may be doing something wrong, but I think the API ought to catch 
> this.  Perhaps close should return silently if there is already a 
> close in progress.
>
> (i have put some instrumentation in the code, so line numbers may be 
> approximative).
>
>
> java.lang.Throwable
>         at 
> net.outer_planes.jso.AbstractStream$Input.process(AbstractStream.java:143) 
>
>         at 
> net.outer_planes.jso.AbstractStream.process(AbstractStream.java:952)
>         at 
> net.outer_planes.jso.AbstractStream.close(AbstractStream.java:854)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacques Belissent | 13 Feb 2004 02:05
Picon

handling of "ping" bytes

Hi,

It appears that some jabber clients periodically send spaces to the 
server.  As if to say: i'm still alive, don't shut the connection. 
Whatever the reason is, these ping sequences are not handled by JSO as 
far as I see.

What happens is that IxpParser.parse() stays in a loop until further the 
recently added PARSE_TIMEOUT is reached.  (not sure whether it was for 
that reason).

100 milliseconds is still a lot of processing if you multiply that by a 
lot of sessions.  On the other hand it might be too short if cpu 
resources are short and the thread gets swaped out in the middle of the 
loop.  And calling getCurrentTimeMillis in each iteration may also have 
a visible perf impact.

I was wondering whether doing something like this woudl be more 
efficient (in the parse method while loop)

...
           if (input.length() == previousInput.length() &&
                input.trim().length() == 0) {
                log.warn("same old blank data, input=[" + input + "]");
                ctx.clearBuffer();
                input = input.trim();
            }
...
            previousInput = input;
(Continue reading)

Permalink | Reply | 0 comments |

Gmane