When will the HTTP Binding feature be available on Connection Manager?

Openfire Openfire Dev
21

webdev wrote:

First i’‘m not quite sure where it comes from or if it’'s been discussed already but it seems that the http binding admin page has some problems applying/modifying the params you set.

Basically i believe the daemon can’'t release the ports you set in the custom ports, when changing them and pushing the save button, it falls back to “disabled” and netstat shows the ports are still active. When you select the admin console ports then it applies the setup successfully.

Don’‘t get me wrong the custom ports do work for http binding, i’'m using 8080 on my test server.

So, you are talking about when changing to admin console ports from the custom http bind ports? I am not sure I understand what setting you are changing and what behavior you are seeing. Can you elaborate more please?

Thanks,

Alex

22

Alex,

Could you post the portion of httpd.conf that you have for what you described above for forwarding requests? I’'m getting service unavailable immediately upon sign-in.

Thanks.

23 
LoadModule proxy_http_module modules/mod_proxy_http.so
....
ProxyPass /http-bind http://localhost:9090/http-bind
ProxyPassReverse /http-bind http://localhost:9090/http-bind
ProxyTimeout 10000
24
  • for othe readers this message has nothing to do with a jwchat/jabber client setup -

AWenckus wrote:

So, you are talking about when changing to admin console ports from the custom http bind ports? I am not sure I understand what setting you are changing and what behavior you are seeing. Can you elaborate more please?

well part of the problem has to do with the startup script.

i think i installed the init.d startup script from the 3.1.1 stable version, not sure if it screws up with 3.2.0alpha but sending a stop command will actualy start a new wildfire daemon.

Of course it won’‘t start properly for the ports are already used by the first instance and so on… so for the moment i can’'t get wildfire to stop with the shell scripts provided, it only stops properly when i use the “Stop” button on the admin page…

i’‘ll customize an init.d script “the debian way” using start-stop-daemon but if the root “wildfire.sh” script can’‘t acknowledge a stop command then it’'ll be more trooblesome than that…

Now even when only one wildfire is started, at least i think so, i still get the http binding settings problems in the admin.

applying “new” settings from the admin produces various results :

  • if wildfire is started with http-binding enabled and with custom ports, although everything works fine, if i simply click on “Save settings” without making any changes to the settings, i will get the following message in the error log and the admin will show me that the http binding is “disabled”, and i won’'t be able to enable it again, not until i restart wildfire or switch to admin ports.

2006.11.10 11:41:02 org.jivesoftware.wildfire.HttpServerManager.changeHttpBindPorts(HttpServerManage r.java:476) Error starting HTTP bind service

java.lang.IllegalStateException: Timer already cancelled.

Despites the above error and admin display, the custom ports are still active…

So basically wildfire gets confused with its own current config and fails to release the ports and probably also fails to save the new configuration.

Upon restart it will use the previous settings, http-binding enabled with custom ports.

  • Now if i try to enable the binding again with the custom ports selected then i get the following error, multiple times :

2006.11.10 11:48:34 org.jivesoftware.wildfire.HttpServerManager.changeHttpBindPorts(HttpServerManage r.java:476) Error starting HTTP bind service

org.mortbay.util.MultiException[java.lang.InstantiationException: org.jivesoftware.wildfire.http.HttpBindServlet, java.net.BindException: Address already in use, java.net.BindException: Address already in use]

if you need the full error reports i can send them to you.

hope it helps and it’‘s not just my setup that’'s completely screwed up

webdev

25

Now for the jwchat problem here’‘s what i’'m getting in live http headers plugin when i login to an existing account :

HTTP/1.x 403 Toofrequentpollingminimumintervalis5%2Ccurrentinterval+0

before that i get a bunch of

HTTP/1.x 200 OK

i’‘ll try to check it out, not sure i’'ve read something about that yet…

26

webdev wrote:

2006.11.10 11:41:02 org.jivesoftware.wildfire.HttpServerManager.changeHttpBindPorts(HttpServerManage r.java:476) Error starting HTTP bind service

java.lang.IllegalStateException: Timer already cancelled.

Could you post the full stack trace of this error as I believe this one is causing the other error?

Thanks,

Alex

27

Yea, I was having the same issue with JWChat where it didn’'t support the minimum polling interval. As a temporary fix for this you can set the polling interval to zero by setting the JiveProperty: xmpp.httpbind.client.requests.polling to 0

Alex

28

@AWenckus

the error is isolated, the other ports errors “address already in use” are produced by a separate event…

here’'s the full error i get :

2006.11.10 11:41:02 org.jivesoftware.wildfire.HttpServerManager.changeHttpBindPorts(HttpServerManage r.java:476) Error starting HTTP bind service

java.lang.IllegalStateException: Timer already cancelled.

at java.util.Timer.sched(Timer.java:354)

at java.util.Timer.schedule(Timer.java:222)

at org.jivesoftware.wildfire.http.HttpSessionManager.start(HttpSessionManager.java :80)

at org.jivesoftware.wildfire.http.HttpBindServlet.init(HttpBindServlet.java:59)

at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:400)

at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:254)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38)

at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:569)

at org.mortbay.jetty.servlet.ServletHandler.doStart(ServletHandler.java:142)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38)

at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119)

at org.mortbay.jetty.Server.doStart(Server.java:210)

at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38)

at org.jivesoftware.wildfire.HttpServerManager.changeHttpBindPorts(HttpServerManag er.java:473)

at org.jivesoftware.wildfire.HttpServerManager.setHttpBindPorts(HttpServerManager. java:411)

at org.jivesoftware.wildfire.admin.http_002dbind_jsp.handleUpdate(http_002dbind_js p.java:34)

at org.jivesoftware.wildfire.admin.http_002dbind_jsp._jspService(http_002dbind_jsp .java:91)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1050)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1041)

at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:65)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1041)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1041)

at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:69)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1041)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1041)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:354)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)

at org.mortbay.jetty.Server.handle(Server.java:269)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430)

at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:701 )

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)

at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

29

AWenckus wrote:

Yea, I was having the same issue with JWChat where it didn’'t support the minimum polling interval. As a temporary fix for this you can set the polling interval to zero by setting the JiveProperty: xmpp.httpbind.client.requests.polling to 0

okay xmpp.httpbind.client.requests.polling = 0, solves the 503 error

login in works, online status stays alive for a few seconds then i get a Proxy Error 502, “Service unavailable” popup.

I’‘m trying to find out what’‘s going on exactly, i’‘m using apache 2 and i’‘m doing the tests with the proxy setup you’'ve posted earlier in this thread.

my apache error log reports that :

proxy: error reading status line from remote server localhost

proxy: Error reading from remote server returned by /wildfire-http-poll/

/wildfire-http-poll/ being the url i use to access wildfire http binding.

webdev

30

I am not terribly familiar with Apache but how i resolved this issue was by lowering the “wait” value, this value is controlled my the client though so it will take some modification of the JWChat source. I may add a jiveProperty for this, and the lower of the two values will be used, the one from the client and the one from Wildfire. The “wait” value indicates how long an HTTP connection should be held open before a response is sent to the client, I have found lowering this value to ten eliminates the proxy error from Apache, though I am not exactly sure why.

The new value has been added to svn. The jiveProperty that was added was xmpp.httpbind.client.requests.wait, specify a value of 10 for that and it should suffice for now.

Thanks,

Alex

31

Okay

could you just give me some details on the source of this problem…

I’'m a bit confused by the various timers involved and if the error comes from the client the server or the proxy setups…

i’'ve checked jwchat JS codes in the file JSJaCHttpBindingConnection.js and it has two constants that are probably related to the communication process, which are :

var JSJaCHBC_MAX_HOLD = 1;

var JSJACHBC_MAX_WAIT = 300;

i’‘ve tried to change (lower and increase) the max_wait value but it didn’'t make any difference so far…

and of course you also have the polling frequency value defiened in the main config file (config.js)

var timerval = 2000; // poll frequency in msec

i can also see in Live HTTP Headers that Keep-Alive is set at 300…

I’'ll try to see if i can do something with the svn version

thx

webdev

32

i’'ve tested a nightly build with your xmpp.httpbind.client.requests.wait property (set at 10) and it works just fine with jwchat…

thx

webdev

33

i’'m still testing a wildfire http-bind setup with jwchat and i have a problem with the search plugin.

when i try to use the search window in jwchat i do get the “search” service implemented by wildfire search plugin with the three checkbox options and the search field but when submitting a search i get no results at all…

I was wondering if it could have anything to do with the new wildfire http-binding feature or if i should try to debug that on jwchat side…

I should also mention that there are a few other things that won’‘t work properly with jwchat, such as the “rooms list” which won’'t return existing rooms on the server…

34

My initial suspicion is that these are JWChat issues. After the initial session is created there is really no awareness from the HTTP Binding perspective about the contents of what is sent and received, so, I don’‘t see how the HTTP Binding service could cause this issue. That said, I wouldn’'t rule it out, there are a lot of moving parts - so if you could debug anything to get us some perspective on what is going on that would be good. It is sending an IQ for search so there should be a response from Wildfire, we just need to know if this is being ignored or not, or what the story is.

Thanks,

Alex

35

okay sorry it’'s a stupid javascript error in jwchat… works like a charm

36

hello again,

i’'ve been trying to track down a problem i have with my wildfire http-bind / jwchat setup…

i appears that messages sent by jwchat get their encoding broken and i can’'t find out why or where…

here’‘s a test i’'ve made on that wildfire server using two clients : jwchat < wildfire > miranda

when i send a non ascii char like “é” from jwchat to miranda it gets broken and i get something like “é” in Miranda… On the other hand when i send a special char from miranda, the jwchat client gets a properly formated char…

jwchat is supposed to work exclusively with utf-8 so it should be sending messages encoded in utf-8 to wildfire…

any idea where the problem could come from ?

thx

37

Seems like a jwchat problem, though I can’‘t be positive. This is my suspicion as sending from miranda is working correctly and there isn’'t any special packet handling logic that is part of the http binding, it basically just hands off to Wildfire and says, “Do your thing”. I will check in Wildfire to see if the encoding is getting messed up somewhere perhaps.

Alex

38

just to make sure my description is clear, the miranda client does not use http-bind but the regular jabber protocol…

i’‘ve tried to locate any utf encoding code from the JSJAC javascript that jwchat uses but couldn’'t find any.

JWChat pages are tagged as UTF-8 so i guess the browser takes care of encoding any input chars to the current charset…

I’‘ve tried to intercept POST data sent by jwchat to check if the chars are properly formatted there but haven’'t managed to get something relevant yet…

39

okay i’'ve been able to debug that charset encoding problem a little further…

it seems that messages going thru wildfire http-bind get encoded to utf-8 even though they were already encoded in utf-8, rendering them broken to any client display…

I’'ve introduced an utf-8 decoding function in jwchat chat window and made it decode any incoming messages. Then the double utf encoding falls back to proper utf-8 and gets displayed in jwchat windows as it should be…

JWChat dev tells me it’'s probably a wildfire bug coz JSJAC code and jwchat functions do not do any particular encoding… strings coming out of the browser are sent according to the page encoding which is of course set to utf-8 on all jwchat documents…

he also told me that the only place where the charset info is set is in that part of js code :

var r = XmlHttp.create();

try {

r.open(“POST”,this._httpbase,async);

r.setRequestHeader(’‘Content-Type’’,’‘text/xml; charset=utf-8’’);

could it be possible that wildfire does not detect the request encoding and thus decides to encode to utf-8 the output making the response sent to the recipient encoded twice ?

40

Hmmm… okay, so, outgoing from JWChat is being double encoded but incoming is working fine. Just wanted to clarify.