-
1. Re: Netty Subsystem for WildFly
dmlloyd Jun 21, 2013 10:30 AM (in response to beve)1 of 1 people found this helpfulWe 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).
-
2. Re: Netty Subsystem for WildFly
ctomc Jun 21, 2013 11:39 AM (in response to beve)1 of 1 people found this helpfulHi,
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
-
3. Re: Netty Subsystem for WildFly
beve Jun 24, 2013 9:10 AM (in response to dmlloyd)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.
-
4. Re: Netty Subsystem for WildFly
beve Jun 24, 2013 9:14 AM (in response to ctomc)- 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!