Hi Nadav/Friends, Is it okay for you if I split this second patch in a set as follows: - fix the patches that don't work on tomcat 9
- reorganize the patches by file, so, if it fails to apply the patch somewhere, it would fail per file For example, currently, If the patch fails on the second patch, tomcat-users.xml will be ok and it will break server.xml But I would like to apply all changes on tomcat-users.xml first, then, all changes on server.xml and so on Not only it's clear but also, makes easier to find an issue in case it happens in the middle of the process - rename patches so they are consistent In this case, configure-web-admin-user.patch and assign-admin-gui-role-to-tomcat-user.patch are talking about the same tomcat user but one calls web user and the other calls tomcat user Regarding the Apache Portable Runtime, I know I should comment at the issue but anyway I think it's better to let it die because as far as I know: - the performance difference isn't so big after java nio/nio2 (although tomcat crashes with nio2) - the ssl thing that people used to do with apr are somehow insecure (apr uses openssl for this) and can be moved to a reverse proxy (apache httpd/nginx) which is better and off-load tomcat, of course, springboot with embedded tomcat would be the best scenario... Of course, I might be wrong, if anyone knows it better, please, let us know So, I might work on it I'm interested in tomcat mainly because I'm used to it at work But I don't have any OSv env. in production with it (which is a pity) Kind Regards, Geraldo Netto Sapere Aude => Non dvcor, dvco http://exdev.sf.net/ On Fri, 7 Sep 2018 at 21:47, Geraldo Netto <geraldone...@gmail.com> wrote: > Hello Nadav/Friends, > > >> On Wed, Sep 5, 2018 at 6:15 AM, geraldo netto <geraldone...@gmail.com> >>>> wrote: >>>> >>>>> reorganise patches to make it easier to change in the future >>>>> >>>> >>>> I didn't understand the purpose of this patch. It seems you moved some >>>> of the >>>> patches out of the "perf" subdirectories (I don't know why they were >>>> there, but >>>> at least all the patches were in the same directory), and mostly >>>> modified comments >>>> in the other patches. Why? >>>> >>>> Also, I think your modification to 0007-force-HTTP-NIO-connector.patch >>>> contains an >>>> important change, it's not a "reorganization". I would have liked to >>>> see it as >>>> a separate patch, and not combined with random renames, comment >>>> changes, etc. >>>> >>> >>> I called reorganisation because the patches were out of order >>> >>> this is the old list of patches (each colour is a different file): >>> 0001-configure-web-admin-user.patch >>> 0002-change-http-port-to-8081.patch >>> 0003-assign-admin-gui-role-to-tomcat-user.patch >>> 0004-disable-Jasper-development-mode.patch >>> 0005-bump-up-number-of-threads.patch >>> 0006-Add-script-managment-role-to-tomcat-user.patch >>> 0007-Use-bio-connector-explicitly.patch >>> 0008-Do-not-enable-AJP-connector.patch >>> >>> this is the new list of patches (each colour is a different file): >>> 0001-add-admin-user.patch >>> 0002-grant-admin-gui-to-tomcat-user.patch >>> 0003-grant-manager-script-to-tomcat-user.patch >>> 0004-disable-jasper-development-mode.patch >>> 0005-change-http-port-to-8081.patch >>> 0006-increase-number-of-threads.patch >>> 0007-force-HTTP-NIO-connector.patch >>> 0008-disable-AJP-connector.patch >>> >>> as you can see, the patches are grouped by file now >>> >> >> My problem is that you mixed together in one patch three different things: >> >> 1. A change relevant to this patch series - changing the choice of BIO to >> NIO is important because Tomcat 9 no longer supports BIO. Patches which no >> longer applied in Tomcat 9 and needed to be fixed. That sort of thing. >> 2. Renaming the patches >> 3. Various random modifications in comments and headings inside the >> patches. >> >> 1 is important in this series and I'll commit it. The value of the >> other stuff is dubious so you'll have to convince me it makes sense. >> >> >>> >>> NIO vs BIO is a important thing indeed >>> more details here: >>> https://events.static.linuxfound.org/sites/events/files/slides/TomcatConnectorsEU_0.pdf >>> >>> But I can revert this to the old behaviour if you find interesting >>> >> >> If I understand correctly, Tomcat 9 dropped support for BIO, didn't it? >> So we can't "revert" to it and need to switch to NIO. >> It would be nice if you could verify that with NIO, tomcat still works, >> and hopefully with similar performance to the old Tomcat app. >> >> >>> Also, there is this Java NIO2 general protection fault from my past >>> emails >>> >> >> Yes. Someone will have to debug this, it doesn't look familiar to me. >> Also, to be honest, I have no idea what is the difference between NIO and >> NIO2, or what do we >> lose by using the older-sounding "NIO" instead of the shiny-new "NIO2". >> >> >>> >>> In any case, I think we should change the approach with Tomcat patches... >>> Because the number of lines between versions may change, >>> >> >> But does this matter? This is why patches have context - so the patch can >> still be applied even after line number changed. >> Do some or all of these patches stopped applying? >> > > For some reason, the patches from tomcat 8 didn't work on tomcat 9 out of > box > I didn't spend time checking why because those patches were also 'out of > order' > in a sense that they were changing different files in a non sequencial way > like below and that's annoy me: > > 0001-configure-web-admin-user.patch => conf/tomcat-users.xml > 0002-change-http-port-to-8081.patch => conf/server.xml > 0003-assign-admin-gui-role-to-tomcat-user.patch => conf/tomcat-users.xml > 0004-disable-Jasper-development-mode.patch => conf/web.xml > 0005-bump-up-number-of-threads.patch => conf/server.xml > 0006-Add-script-managment-role-to-tomcat-user.patch => > conf/tomcat-users.xml > 0007-Use-bio-connector-explicitly.patch => conf/server.xml > 0008-Do-not-enable-AJP-connector.patch => conf/server.xml > > > Kind Regards, > > Geraldo Netto > Sapere Aude => Non dvcor, dvco > http://exdev.sf.net/ > > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
