Solved

otero — Fri, 16 Apr 2010 18:00:16 +0000

Hello again.

So, i finally got the problem! My components were sending an extra stanza after the handshake! And I guess that Openfire is cool with that, but ejabberd not! :)

Thanks for your help!

Hi, All responses from the

otero — Thu, 15 Apr 2010 16:50:11 +0000

Hi,

All responses from the component fail to reach the clients! Also every local components seem to work correctly. I have a bunch of external components and all have this same problem!

I will investigate further and see what I can get. I don't know if i'm able to compile from source, and I'm completely new to Erlang also.

I'm starting to try older versions of ejabberd :)

Thanks for your help!

Strange problem

mfoss — Thu, 15 Apr 2010 10:54:00 +0000

Strange, it seems that it should work.

If you look at the source code file ejabberd_receiver.erl line 320, you see the line that prints the last log line:

?DEBUG("Received XML on stream = ~p", [binary_to_list(Data)]),

After that, the receiver code still does more things. You can apply this patch that will show more information about what happens there.

--- a/src/ejabberd_receiver.erl
+++ b/src/ejabberd_receiver.erl
@@ -319,15 +319,20 @@ process_data(Data,
                    c2s_pid = C2SPid} = State) ->
     ?DEBUG("Received XML on stream = ~p", [binary_to_list(Data)]),
     XMLStreamState1 = xml_stream:parse(XMLStreamState, Data),
+    ?DEBUG("Updating the shaper", []),
     {NewShaperState, Pause} = shaper:update(ShaperState, size(Data)),
     if
        C2SPid == undefined ->
+           ?DEBUG("c2spid is undefined", []),
            ok;
        Pause > 0 ->
+           ?DEBUG("pausing a little, later activate the socket", []),
            erlang:start_timer(Pause, self(), activate);
        true ->
+           ?DEBUG("activating the socket", []),
            activate_socket(State)
     end,
+    ?DEBUG("Ok, let's continue", []),
     State#state{xml_stream_state = XMLStreamState1,
                shaper_state = NewShaperState}.

If that doesn't show you any strange behaviour, maybe the problem is later on, and would require a harder investigation. Do other queries to the component work, or all responses are 'dropped' like in this case? If you configured a shaper, or access, for that component in ejabberd.cfg, try to modify them. Does local components (like the MUC service of mod_muc) work correctly? If you have any other external component connected (another transport...), does it work correctly?

Looking at ejabberd_receiver.erl history, the last relevant change was in ejabberd 2.1.0 (BOSH module optimization and clean-up). I imagine somebody would have reported the problem if it were introduced so many time ago. If you ran out of ideas, you can try with ejabberd 2.0.5, and report if that old version works correctly.

ejabberd - Comments for "Discovery info for external components isn&#039;t delivered"

Solved

Hi, All responses from the

Strange problem

ejabberd - Comments for "Discovery info for external components isn't delivered"