Netty Subsystem for WildFly

[beve]

Hi,

We (AeroGear) have a standalone Netty based server which we would like to be able to embed within WildFly. For this we have tried creating a subsystem for Netty, WildFly subsystem for Netty .

The current subsystem tries to play nicely with WildFly by using socket-binding and thread-factory, but this might not be enough. We would be very interested in hearing what you think about this idea and if you think it's something we should pursue, or if you have other ideas please let  us know.

Thanks,

/Dan

[dmlloyd]

We had determined that the best way to support I/O systems is to expose only the basic I/O parameters (see Tomaž' I/O subsystem) and a subsystem for the protocol itself (e.g. Remoting, HornetQ, etc.).  Whether a server is based on Netty or whatever else is not something the user should have to care about; all network tuning parameters should be in one place, and referenced by the higher-level subsystems as needed.  We do have plans to extend the I/O subsystem to cover Netty as well (I was thinking the easiest solution would be to create a Netty XNIO backend, which has been done in the past; Norman was going to look into this but I don't know if anything ever came of it).

[ctomc]

Hi,

Not touching subject of purpose & reasons behind the subsystem, here are just my comments on the code itself.

• why use extra xml element <netty> if it already goes for netty subsystem, drop it as it is redundant
• general practice is that if you specify class in configuration you should also provide module-name from where it should be loaded
• do not reference thread factories, as in reference threads subsystem, as it is going to be removed in future, instead use threads subsystem API to embed resource definition/parser in your subsystem, see EJB3 subsystem for that

--

tomaz

[beve]

Thanks of the quick response!

We had determined that the best way to support I/O systems is to expose only the basic I/O parameters (see Tomaž' I/O subsystem) and a subsystem for the protocol itself (e.g. Remoting, HornetQ, etc.).

Ah, so we should create a subsystem specific to our application instead. I'll take a look at the Remoting and HornetQ susbystems and also look as the I/O subsystem.

We do have plans to extend the I/O subsystem to cover Netty as well (I was thinking the easiest solution would be to create a Netty XNIO backend, which has been done in the past; Norman was going to look into this but I don't know if anything ever came of it).

Cool, I'll ping Norman and see what the status is here.

[beve]

• why use extra xml element <netty> if it already goes for netty subsystem, drop it as it is redundant

You are right, I'll make sure to remove that (or if we go with a different approach follow this advise with it)

• general practice is that if you specify class in configuration you should also provide module-name from where it should be loaded

Do you know of any place that I can look to see how this is done?

• do not reference thread factories, as in reference threads subsystem, as it is going to be removed in future, instead use threads subsystem API to embed resource definition/parser in your subsystem, see EJB3 subsystem for that

Ah interesting, I'll check out the EJB3 subsystem.

Thanks!