Description of problem: The documentation lacks any information on the use of 'netty tranport support' over http port, the netty-servlet transport support for remote JMS clients. This helps users to configure the inbuilt netty-servlet to offer JMS clients to communicate over the configured HTTP port. Thus it eliminates the need to open a separate port for JMS clients to communicate to the broker, specially when the communication occurs over a firewall. -Note- Although it's possible for JMS clients to communicate over the HTTP port with the help of netty-servlet support; the netty service over HTTP cannot be used to configure a JBOss-EAP-6.x servers to setup a HornetQ cluster. Hence, please state this information on a separate box so that the users would know this limitation when using the netty-servlet. Version-Release number of selected component (if applicable): JBoss-EAP-6.2, HornetQ-2.3.x How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Russell For the record, Tyronne contacted me directly yesterday and was going to update this ticket with triage information. He must have got tied up with other work, so I'll do it for him. ==Summary== Add this community content into enterprise docs: http://docs.jboss.org/hornetq/2.3.0.Final/docs/user-manual/html_single/#configuring-transports Exclude core API content contained in this section unless core API content is supported in EAP. Include the note in #Description. Ask tywickra if you get stuck. ==IRC log follows== <tywickra> Basically, we want to tell the customers "Don't use netty servlet transport to configure a cluster" But we don't mention anything on netty servlet transport in the documentation. <jmorgan> So you need Russell to get that recommendation into the docs. <tywickra> Yes, so before we say "Z is not supported", we need to explain what is "Z" is all about <jmorgan> That sounds like we need to write a small conceptual piece on Netty Servlet Transport <tywickra> You beat me to it :-) <jmorgan> :D So this would go into the HornetQ docs for EAP 6.2 and greater. <tywickra> Yes, true <jmorgan> the bug you linked seems to be focused on the code side of the issue what I think needs to happen is that the issue is cloned so you guys can continue working on the code. The cloned issue will be used to handle the docs. That way docs won't hold up the code stuff. Unless the linked BZ *is* the docs bug. <tywickra> Oops My apologies, I pasted the incorrect BZ <jmorgan> Oh, OK. Glad I checked :D <tywickra> Here it is : https://bugzilla.redhat.com/show_bug.cgi?id=1065238 <jmorgan> RGR, that's making more sense ;) <tywickra> sorry, had a dumb moment with my copy+past ability :-D <jmorgan> lol Is there any community content about NTS at the moment? http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/configuring-transports.html is this close to the mark? <tywickra> Basically, the netty servlet can only be used to connect to a standalone single HornetQ instance. It doesn't support failover either : https://bugzilla.redhat.com/show_bug.cgi?id=1073497 I would use 2.3.0 docs, that's more closer to what we have released in EAP-6.2 <jmorgan> http://docs.jboss.org/hornetq/2.3.0.Final/docs/user-manual/html_single/#configuring-transports <tywickra> bingo <jmorgan> So it's worth capturing this chapter in its entirety in the EAP 6.2 docs, correct? Is there any unsupported stuff currently mentioned in that chapter? * jmorgan is not familiar enough with EAP anymore to make the judgement, and I know the EAP docs team will be asking the same question. <tywickra> I would weed out any content related to the core API <jmorgan> Good tip. <tywickra> Unless you're happy to ship the core API with the official doc :-) <jmorgan> That is not my call ;) <tywickra> :-) <jmorgan> So the ticket should be updated with a link to the community docs. And specify that content about the core API be excluded. Tell them you've spoken to me about it and we've got it down to that .
Looks good, thanks!
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days