From darran.lofthouse at jboss.com Thu May 1 14:05:22 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 01 May 2014 19:05:22 +0100 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 Message-ID: <53628CE2.9080207@jboss.com> I am just about to work on the outstanding task to enhance the configuration to the HTTP management interface and add some additional capabilities to it so this mail is really a FYI for those interested as numerous teams have interest in this area. The parent Jira issue is here: - https://issues.jboss.org/browse/WFLY-2635 At the moment there are not many configuration options for the HTTP interface and we make a lot of decisions ourselves as to how it is assembled, we now need some additional flexibility. For the admin console there is a desire to enable alternative distribution mechanisms so that the console can be served up from elsewhere. There are no plans to remove the admin console from the WildFly distribution but users may want to switch to a different version. For this reason I plan to add configuration for the /console context to make it possible to either disable the bundles console or to respond to requests for the console with a redirect. When we first authentication approaches for the HTTP management operations we decided to use standard HTTP authentication mechanisms so that clients could be written in many languages without imposing a requirement other than the support of standard mechanisms. This in turn has some problems with web browsers calling the management interface so cross origin resource sharing has been completely disabled to protect against malicious cross site scripting attacks. My intention is that this /management context will remain as a legacy context (not deprecated) so that clients written to use it can still do so - we may choose to have it switched off by default but enabling this context will be a config item. The next step will be the introduction of a new management context with a new name, at this stage I am only looking at configuration but this new context will be updated to support new authentication mechanisms which will be used directly by the console instead of by the web browser. By moving credential handling from the web browser to the console itself we will be able to relax our cross resource sharing restrictions for this context maybe with configuration of allowed origins. This will also allow us to remove the current 'Logout' hack that we have in the console and HTTP interface as the console will be able to control exactly how long credentials are cached for. This will also have a useful side effect of allowing a user to open the admin console multiple times with each instance authenticated as a different user. At that point it will be possible for the console to be used with alternative distribution approaches and also will provide a path where additional SSO mechanisms can be used as these also have a requirement on CORS. I will send round some design ideas / config examples next week but if there are any additional demands on the HTTP management interface in addition to a path to enabling alternative distribution approaches and the enablement of SSO not is the time to speak up ;-) Regards, Darran Lofthouse. From ssilvert at redhat.com Thu May 1 16:03:48 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 01 May 2014 16:03:48 -0400 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: <53628CE2.9080207@jboss.com> References: <53628CE2.9080207@jboss.com> Message-ID: <5362A8A4.2080808@redhat.com> On 5/1/2014 2:05 PM, Darran Lofthouse wrote: > I am just about to work on the outstanding task to enhance the > configuration to the HTTP management interface and add some additional > capabilities to it so this mail is really a FYI for those interested as > numerous teams have interest in this area. > > The parent Jira issue is here: - > https://issues.jboss.org/browse/WFLY-2635 > > At the moment there are not many configuration options for the HTTP > interface and we make a lot of decisions ourselves as to how it is > assembled, we now need some additional flexibility. > > For the admin console there is a desire to enable alternative > distribution mechanisms so that the console can be served up from > elsewhere. There are no plans to remove the admin console from the > WildFly distribution but users may want to switch to a different > version. For this reason I plan to add configuration for the /console > context to make it possible to either disable the bundles console or to > respond to requests for the console with a redirect. We might also need another static-content context in addition to /console. I'm thinking that the Keycloak console will probably need to be accessed from the domain controller in the same manner as the web console. > > When we first authentication approaches for the HTTP management > operations we decided to use standard HTTP authentication mechanisms so > that clients could be written in many languages without imposing a > requirement other than the support of standard mechanisms. This in turn > has some problems with web browsers calling the management interface so > cross origin resource sharing has been completely disabled to protect > against malicious cross site scripting attacks. My intention is that > this /management context will remain as a legacy context (not > deprecated) so that clients written to use it can still do so - we may > choose to have it switched off by default but enabling this context will > be a config item. > > The next step will be the introduction of a new management context with > a new name, at this stage I am only looking at configuration but this > new context will be updated to support new authentication mechanisms > which will be used directly by the console instead of by the web > browser. By moving credential handling from the web browser to the > console itself we will be able to relax our cross resource sharing > restrictions for this context maybe with configuration of allowed > origins. This will also allow us to remove the current 'Logout' hack > that we have in the console and HTTP interface as the console will be > able to control exactly how long credentials are cached for. This will > also have a useful side effect of allowing a user to open the admin > console multiple times with each instance authenticated as a different user. > > At that point it will be possible for the console to be used with > alternative distribution approaches and also will provide a path where > additional SSO mechanisms can be used as these also have a requirement > on CORS. > > I will send round some design ideas / config examples next week but if > there are any additional demands on the HTTP management interface in > addition to a path to enabling alternative distribution approaches and > the enablement of SSO not is the time to speak up ;-) > > Regards, > Darran Lofthouse. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ssilvert at redhat.com Thu May 1 16:08:08 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 01 May 2014 16:08:08 -0400 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: <53628CE2.9080207@jboss.com> References: <53628CE2.9080207@jboss.com> Message-ID: <5362A9A8.5030803@redhat.com> On 5/1/2014 2:05 PM, Darran Lofthouse wrote: > I am just about to work on the outstanding task to enhance the > configuration to the HTTP management interface and add some additional > capabilities to it so this mail is really a FYI for those interested as > numerous teams have interest in this area. > > The parent Jira issue is here: - > https://issues.jboss.org/browse/WFLY-2635 > > At the moment there are not many configuration options for the HTTP > interface and we make a lot of decisions ourselves as to how it is > assembled, we now need some additional flexibility. > > For the admin console there is a desire to enable alternative > distribution mechanisms so that the console can be served up from > elsewhere. There are no plans to remove the admin console from the > WildFly distribution but users may want to switch to a different > version. For this reason I plan to add configuration for the /console > context to make it possible to either disable the bundles console or to > respond to requests for the console with a redirect. > > When we first authentication approaches for the HTTP management > operations we decided to use standard HTTP authentication mechanisms so > that clients could be written in many languages without imposing a > requirement other than the support of standard mechanisms. This in turn > has some problems with web browsers calling the management interface so > cross origin resource sharing has been completely disabled to protect > against malicious cross site scripting attacks. My intention is that > this /management context will remain as a legacy context (not > deprecated) so that clients written to use it can still do so - we may > choose to have it switched off by default but enabling this context will > be a config item. > > The next step will be the introduction of a new management context with > a new name, at this stage I am only looking at configuration but this > new context will be updated to support new authentication mechanisms > which will be used directly by the console instead of by the web > browser. By moving credential handling from the web browser to the > console itself we will be able to relax our cross resource sharing > restrictions for this context maybe with configuration of allowed > origins. This will also allow us to remove the current 'Logout' hack > that we have in the console and HTTP interface as the console will be > able to control exactly how long credentials are cached for. This will > also have a useful side effect of allowing a user to open the admin > console multiple times with each instance authenticated as a different user. What is meant by "moving credential handling from the web browser to the console itself"? > > At that point it will be possible for the console to be used with > alternative distribution approaches and also will provide a path where > additional SSO mechanisms can be used as these also have a requirement > on CORS. > > I will send round some design ideas / config examples next week but if > there are any additional demands on the HTTP management interface in > addition to a path to enabling alternative distribution approaches and > the enablement of SSO not is the time to speak up ;-) > > Regards, > Darran Lofthouse. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Thu May 1 17:43:19 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 1 May 2014 16:43:19 -0500 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: <5362A9A8.5030803@redhat.com> References: <53628CE2.9080207@jboss.com> <5362A9A8.5030803@redhat.com> Message-ID: On May 1, 2014, at 3:08 PM, Stan Silvert wrote: > What is meant by "moving credential handling from the web browser to the > console itself?? He means doing auth in the JS code itself. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Thu May 1 17:45:51 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 1 May 2014 16:45:51 -0500 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: <53628CE2.9080207@jboss.com> References: <53628CE2.9080207@jboss.com> Message-ID: <9EDAB013-F303-4C2A-B954-80DBD6F0664B@redhat.com> We also should look at automating SSL setup, although maybe thats a different topic. On May 1, 2014, at 1:05 PM, Darran Lofthouse wrote: > I am just about to work on the outstanding task to enhance the > configuration to the HTTP management interface and add some additional > capabilities to it so this mail is really a FYI for those interested as > numerous teams have interest in this area. > > The parent Jira issue is here: - > https://issues.jboss.org/browse/WFLY-2635 > > At the moment there are not many configuration options for the HTTP > interface and we make a lot of decisions ourselves as to how it is > assembled, we now need some additional flexibility. > > For the admin console there is a desire to enable alternative > distribution mechanisms so that the console can be served up from > elsewhere. There are no plans to remove the admin console from the > WildFly distribution but users may want to switch to a different > version. For this reason I plan to add configuration for the /console > context to make it possible to either disable the bundles console or to > respond to requests for the console with a redirect. > > When we first authentication approaches for the HTTP management > operations we decided to use standard HTTP authentication mechanisms so > that clients could be written in many languages without imposing a > requirement other than the support of standard mechanisms. This in turn > has some problems with web browsers calling the management interface so > cross origin resource sharing has been completely disabled to protect > against malicious cross site scripting attacks. My intention is that > this /management context will remain as a legacy context (not > deprecated) so that clients written to use it can still do so - we may > choose to have it switched off by default but enabling this context will > be a config item. > > The next step will be the introduction of a new management context with > a new name, at this stage I am only looking at configuration but this > new context will be updated to support new authentication mechanisms > which will be used directly by the console instead of by the web > browser. By moving credential handling from the web browser to the > console itself we will be able to relax our cross resource sharing > restrictions for this context maybe with configuration of allowed > origins. This will also allow us to remove the current 'Logout' hack > that we have in the console and HTTP interface as the console will be > able to control exactly how long credentials are cached for. This will > also have a useful side effect of allowing a user to open the admin > console multiple times with each instance authenticated as a different user. > > At that point it will be possible for the console to be used with > alternative distribution approaches and also will provide a path where > additional SSO mechanisms can be used as these also have a requirement > on CORS. > > I will send round some design ideas / config examples next week but if > there are any additional demands on the HTTP management interface in > addition to a path to enabling alternative distribution approaches and > the enablement of SSO not is the time to speak up ;-) > > Regards, > Darran Lofthouse. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From hbraun at redhat.com Fri May 2 03:27:14 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 2 May 2014 09:27:14 +0200 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: <53628CE2.9080207@jboss.com> References: <53628CE2.9080207@jboss.com> Message-ID: If i understand it correctly, the new auth method you mention has no relation to sso (the brno design decisions, right?). Maybe its worth exploring the commonalities and differences to see if we can move to keycloak right away? Assuming that we dont wont two pssible authentication options. The way i see it keycloak sso would be a replacement for the new auth method you desribe, right? Heiko > Am 01.05.2014 um 20:05 schrieb Darran Lofthouse : > > I will send round some design ideas / config examples next week but if > there are any additional demands on the HTTP management interface in > addition to a path to enabling alternative distribution approaches and > the enablement of SSO not is the time to speak up ;-) From jgreene at redhat.com Fri May 2 22:51:02 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Fri, 2 May 2014 22:51:02 -0400 (EDT) Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: References: <53628CE2.9080207@jboss.com> Message-ID: <28845A50-5F9B-410D-991A-19D5403311FD@redhat.com> I don't believe we want to require SSO out of the box. That would be too much infrastructure for a simple setup. > On May 2, 2014, at 2:27 AM, Heiko Braun wrote: > > If i understand it correctly, the new auth method you mention has no relation to sso (the brno design decisions, right?). Maybe its worth exploring the commonalities and differences to see if we can move to keycloak right away? Assuming that we dont wont two pssible authentication options. The way i see it keycloak sso would be a replacement for the new auth method you desribe, right? > > Heiko > > > >> Am 01.05.2014 um 20:05 schrieb Darran Lofthouse : >> >> I will send round some design ideas / config examples next week but if >> there are any additional demands on the HTTP management interface in >> addition to a path to enabling alternative distribution approaches and >> the enablement of SSO not is the time to speak up ;-) > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Sat May 3 10:31:23 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Sat, 3 May 2014 09:31:23 -0500 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: <28845A50-5F9B-410D-991A-19D5403311FD@redhat.com> References: <53628CE2.9080207@jboss.com> <28845A50-5F9B-410D-991A-19D5403311FD@redhat.com> Message-ID: I agree. Sent from my iPhone > On May 2, 2014, at 9:51 PM, "Jason T. Greene" wrote: > > I don't believe we want to require SSO out of the box. That would be too much infrastructure for a simple setup. > >> On May 2, 2014, at 2:27 AM, Heiko Braun wrote: >> >> If i understand it correctly, the new auth method you mention has no relation to sso (the brno design decisions, right?). Maybe its worth exploring the commonalities and differences to see if we can move to keycloak right away? Assuming that we dont wont two pssible authentication options. The way i see it keycloak sso would be a replacement for the new auth method you desribe, right? >> >> Heiko >> >> >> >>> Am 01.05.2014 um 20:05 schrieb Darran Lofthouse : >>> >>> I will send round some design ideas / config examples next week but if >>> there are any additional demands on the HTTP management interface in >>> addition to a path to enabling alternative distribution approaches and >>> the enablement of SSO not is the time to speak up ;-) >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Sun May 4 14:56:40 2014 From: jason.greene at redhat.com (Jason Greene) Date: Sun, 4 May 2014 13:56:40 -0500 Subject: [wildfly-dev] Short 8.1 CR2 on its way Message-ID: <467DE512-4C6F-4977-8874-3F1C71A7690F@redhat.com> Hi Everyone, As soon as we get a clean CI run on the latest master, I plan to cut a 8.1 CR2 for review. We then need to get a TCK & Tools green light and we can rerelease it as a Final (provided no blockers are uncovered). CR2 fixes some significant issues discovered on CR1, notably a JSF memory leak and some SSL problems on Windows. CR2 also includes the Weld/CR CDI update (1.2 MR spec release), which is why a full TCK rerun is necessary. Thanks -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Sun May 4 15:06:39 2014 From: jason.greene at redhat.com (Jason Greene) Date: Sun, 4 May 2014 14:06:39 -0500 Subject: [wildfly-dev] 8.1 CR2 - Patch Tool Testing Heads-Up Message-ID: <14706E87-37AF-48FE-962F-16B959A004E5@redhat.com> 8.1 will be the first community update to provide a separate download for the patch tool, which allows you to do in-place updates to an existing 8.0 install. Shortly after CR2 is cut, I will provide a link to a separate and different patch file download, along with some instructions for how to use the update with the patch command. I would appreciate everyone trying this out, and reporting back any issues. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From kustos at gmx.net Mon May 5 15:01:02 2014 From: kustos at gmx.net (Philippe Marschall) Date: Mon, 05 May 2014 21:01:02 +0200 Subject: [wildfly-dev] Adding timeout section to datasource management GUI In-Reply-To: <3DA0B7DD-486C-4F53-9378-774807CD5D84@redhat.com> References: <535E940C.2060706@gmx.net> <3DA0B7DD-486C-4F53-9378-774807CD5D84@redhat.com> Message-ID: <5367DFEE.3090306@gmx.net> On 29.04.2014 09:48, Harald Pehl wrote: > Well done! You just missed to add the timeout properties to the AutoBean interface. See my comment on your commit [1] for all the details. > > [1] https://github.com/marschall/core/commit/89df3cb84e26ef5fc525858e3529095af5c53668#commitcomment-6151911 Thank you for your help, we now have most things working [1]. The only thing not yet working is the xa resource timeout for xa datasources. We did the following: - added the mapping to XADataSource - pass XADataSource.class to the FormEditor constructor - added helpAddress.add("xa-data-source", "*"); - use the xaCallback from XADataSourceEditor If you could have another look that would be great. [1] https://github.com/marschall/core/commit/ae985bd5f5ace675f1b2f3164215b0a39cca4ecd Cheers Philippe From darran.lofthouse at jboss.com Tue May 6 05:15:25 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 06 May 2014 10:15:25 +0100 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: <9EDAB013-F303-4C2A-B954-80DBD6F0664B@redhat.com> References: <53628CE2.9080207@jboss.com> <9EDAB013-F303-4C2A-B954-80DBD6F0664B@redhat.com> Message-ID: <5368A82D.1050509@jboss.com> On 01/05/14 22:45, Jason Greene wrote: > We also should look at automating SSL setup, although maybe thats a different topic. +1 That is a separate topic I will start on shortly where I am going to pull together the 'backlog' of SSL related enhancements including the unification of SSL configuration across WildFly. That will in turn lead to the point where we can simplify the enablement and also other items that we have discussed such as strongly encouraging it is enabled. > On May 1, 2014, at 1:05 PM, Darran Lofthouse wrote: > >> I am just about to work on the outstanding task to enhance the >> configuration to the HTTP management interface and add some additional >> capabilities to it so this mail is really a FYI for those interested as >> numerous teams have interest in this area. >> >> The parent Jira issue is here: - >> https://issues.jboss.org/browse/WFLY-2635 >> >> At the moment there are not many configuration options for the HTTP >> interface and we make a lot of decisions ourselves as to how it is >> assembled, we now need some additional flexibility. >> >> For the admin console there is a desire to enable alternative >> distribution mechanisms so that the console can be served up from >> elsewhere. There are no plans to remove the admin console from the >> WildFly distribution but users may want to switch to a different >> version. For this reason I plan to add configuration for the /console >> context to make it possible to either disable the bundles console or to >> respond to requests for the console with a redirect. >> >> When we first authentication approaches for the HTTP management >> operations we decided to use standard HTTP authentication mechanisms so >> that clients could be written in many languages without imposing a >> requirement other than the support of standard mechanisms. This in turn >> has some problems with web browsers calling the management interface so >> cross origin resource sharing has been completely disabled to protect >> against malicious cross site scripting attacks. My intention is that >> this /management context will remain as a legacy context (not >> deprecated) so that clients written to use it can still do so - we may >> choose to have it switched off by default but enabling this context will >> be a config item. >> >> The next step will be the introduction of a new management context with >> a new name, at this stage I am only looking at configuration but this >> new context will be updated to support new authentication mechanisms >> which will be used directly by the console instead of by the web >> browser. By moving credential handling from the web browser to the >> console itself we will be able to relax our cross resource sharing >> restrictions for this context maybe with configuration of allowed >> origins. This will also allow us to remove the current 'Logout' hack >> that we have in the console and HTTP interface as the console will be >> able to control exactly how long credentials are cached for. This will >> also have a useful side effect of allowing a user to open the admin >> console multiple times with each instance authenticated as a different user. >> >> At that point it will be possible for the console to be used with >> alternative distribution approaches and also will provide a path where >> additional SSO mechanisms can be used as these also have a requirement >> on CORS. >> >> I will send round some design ideas / config examples next week but if >> there are any additional demands on the HTTP management interface in >> addition to a path to enabling alternative distribution approaches and >> the enablement of SSO not is the time to speak up ;-) >> >> Regards, >> Darran Lofthouse. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > From darran.lofthouse at jboss.com Tue May 6 05:49:48 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 06 May 2014 10:49:48 +0100 Subject: [wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635 In-Reply-To: <5362A8A4.2080808@redhat.com> References: <53628CE2.9080207@jboss.com> <5362A8A4.2080808@redhat.com> Message-ID: <5368B03C.5010101@jboss.com> In general however this configuration is structured I think it does make sense to structure it in a way that would allow additional contexts to be added, that way whether it is used as an EE server or as the cut down core with something else added on top alternatives could be added. One point to keep in mind however is at the moment we are talking about something running in a host controller so we have no access to a servlet container. On 01/05/14 21:03, Stan Silvert wrote: > We might also need another static-content context in addition to > /console. I'm thinking that the Keycloak console will probably need to > be accessed from the domain controller in the same manner as the web > console. From hpehl at redhat.com Tue May 6 07:50:36 2014 From: hpehl at redhat.com (Harald Pehl) Date: Tue, 6 May 2014 13:50:36 +0200 Subject: [wildfly-dev] Adding timeout section to datasource management GUI In-Reply-To: <5367DFEE.3090306@gmx.net> References: <535E940C.2060706@gmx.net> <3DA0B7DD-486C-4F53-9378-774807CD5D84@redhat.com> <5367DFEE.3090306@gmx.net> Message-ID: I tried your branch in GWT dev mode and it turned out that you're using the diamond operator which is not supported by GWT 2.5.x (the GWT version used in HAL). Please see my comments on the branch on how to fix that. Running the app in GWT dev mode is always a good idea, since the log view gives valuable feedback. Besides that your code works for me (including the XA resource timeout) .: Harald Am 05.05.2014 um 21:01 schrieb Philippe Marschall : > > > On 29.04.2014 09:48, Harald Pehl wrote: >> Well done! You just missed to add the timeout properties to the AutoBean interface. See my comment on your commit [1] for all the details. >> >> [1] https://github.com/marschall/core/commit/89df3cb84e26ef5fc525858e3529095af5c53668#commitcomment-6151911 > > > Thank you for your help, we now have most things working [1]. The only thing not yet working is the xa resource timeout for xa datasources. > > We did the following: > - added the mapping to XADataSource > - pass XADataSource.class to the FormEditor constructor > - added helpAddress.add("xa-data-source", "*"); > - use the xaCallback from XADataSourceEditor > > If you could have another look that would be great. > > [1] https://github.com/marschall/core/commit/ae985bd5f5ace675f1b2f3164215b0a39cca4ecd > > Cheers > Philippe --- Harald Pehl JBoss by Red Hat http://hpehl.info From tomaz.cerar at gmail.com Thu May 8 08:57:54 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 8 May 2014 14:57:54 +0200 Subject: [wildfly-dev] http-executor In-Reply-To: References: Message-ID: Hi, your question is way to generic to properly answer it. What I can say is that yes we did add few more options to undertow listeners and few other areas in undertow subsystem. But without any concrete example what you would like to have or what does not work for you I cannot help you. and please, keep discussion about this on wildfly-dev mailing list as it is interesting topic for many people. -- tomaz On Thu, May 8, 2014 at 9:28 AM, Hamed Hatami wrote: > Hi, > > Is it possible that in wildfly 8.1.0 hase more management on websocket > connection and session at undertow ? > > I wanna handle connection timeout to do somethings > > Regards, > Hamed Hatami > On Feb 18, 2014 1:20 PM, "Toma? Cerar" wrote: > >> Hi, >> >> undertow has completely different semantics to what jboss web had before. >> >> Undertow uses XNIO worker(s) which are the ones handling the thread pool >> and few other things. >> You can configure workers in IO subsystem and tell http listener which >> one to use. >> >> By default in configuration we ship we have one worker named "default" >> defined and all listeners use it. >> >> But if you want to have separate workers (thread pools) per worker, all >> you need to do is define new worker in IO subsystem and then reference it >> in http-listener worker="name-of-your-worker-in-io-subsystem" >> >> Just bit of note, we did mistake with default values for default worker >> in 8.0.0.Final release and will fix that in 8.0.1 >> >> In our testing we got best performance when io-threads ware set to number >> of logical cpus * 2 and task-max-threads set to number of cpus * 16. >> This will be defaults we will probably have in 8.0.1 as they perform >> optimal. >> >> >> -- >> tomaz >> >> >> On Tue, Feb 18, 2014 at 9:37 AM, Hamed Hatami wrote: >> >>> Hi, >>> >>> I want to use http-executor for my http-listener but it can not possible >>> >>> what is the solution? >>> >>> Regards, >>> Hamed Hatami. >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140508/75cd0e7d/attachment.html From hamedhatami2012 at gmail.com Thu May 8 10:02:37 2014 From: hamedhatami2012 at gmail.com (Hamed Hatami) Date: Thu, 8 May 2014 18:32:37 +0430 Subject: [wildfly-dev] Websocket session management Message-ID: Hi, I wanna manage my websocket connection or session when to connecttoserver at undertow by java client and when the server is not available , the client try to connect without exception and there is not any timeout to handle it Please help me Regards, Hamed Hatami -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140508/a8626bde/attachment.html From rory.odonnell at oracle.com Fri May 9 05:22:17 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Fri, 09 May 2014 10:22:17 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b11, JDK 8u20 b13 and JDK 7u60 b15 are available on java.net Message-ID: <536C9E49.3050002@oracle.com> Hi Guys, Early Access builds for JDK 9 b11 , JDK 8u20 b13 and JDK 7u60 b15 are available on java.net. As we enter the later phases of development for JDK 7u60 & JDK 8u20 , please log any show stoppers as soon as possible. Rgds, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140509/381ee286/attachment.html From kustos at gmx.net Mon May 12 15:05:31 2014 From: kustos at gmx.net (Philippe Marschall) Date: Mon, 12 May 2014 21:05:31 +0200 Subject: [wildfly-dev] Adding timeout section to datasource management GUI In-Reply-To: References: <535E940C.2060706@gmx.net> <3DA0B7DD-486C-4F53-9378-774807CD5D84@redhat.com> <5367DFEE.3090306@gmx.net> Message-ID: <53711B7B.4050508@gmx.net> On 06.05.2014 13:50, Harald Pehl wrote: > I tried your branch in GWT dev mode and it turned out that you're using the diamond operator which is not supported by GWT 2.5.x (the GWT version used in HAL). Please see my comments on the branch on how to fix that. Running the app in GWT dev mode is always a good idea, since the log view gives valuable feedback. > > Besides that your code works for me (including the XA resource timeout) Thank you for your help, here's the pull request [1] [1] https://github.com/hal/core/pull/14 Cheers Philippe From jason.greene at redhat.com Mon May 12 17:23:04 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 12 May 2014 16:23:04 -0500 Subject: [wildfly-dev] CR2 Released (Was: Short 8.1 CR2 on its way) In-Reply-To: <467DE512-4C6F-4977-8874-3F1C71A7690F@redhat.com> References: <467DE512-4C6F-4977-8874-3F1C71A7690F@redhat.com> Message-ID: This has now been published. After a short round of additional testing we should be able to cut the Final in under a week. On May 4, 2014, at 1:56 PM, Jason Greene wrote: > Hi Everyone, > > As soon as we get a clean CI run on the latest master, I plan to cut a 8.1 CR2 for review. We then need to get a TCK & Tools green light and we can rerelease it as a Final (provided no blockers are uncovered). > > CR2 fixes some significant issues discovered on CR1, notably a JSF memory leak and some SSL problems on Windows. CR2 also includes the Weld/CR CDI update (1.2 MR spec release), which is why a full TCK rerun is necessary. > > Thanks > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Mon May 12 17:27:01 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 12 May 2014 16:27:01 -0500 Subject: [wildfly-dev] Master is now 9.x! Message-ID: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jperkins at redhat.com Mon May 12 18:13:59 2014 From: jperkins at redhat.com (James R. Perkins) Date: Mon, 12 May 2014 15:13:59 -0700 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> Message-ID: <537147A7.80107@redhat.com> Yay! On 05/12/2014 02:27 PM, Jason Greene wrote: > After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. > > Thanks! > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat From jorsol at gmail.com Mon May 12 18:40:25 2014 From: jorsol at gmail.com (=?ISO-8859-1?Q?Jorge_Sol=F3rzano?=) Date: Mon, 12 May 2014 16:40:25 -0600 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <537147A7.80107@redhat.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <537147A7.80107@redhat.com> Message-ID: Is there any special feature planned that deserve the jump to 9.x (ex. pre-Java EE 8 support, major rewrite or b leeding edge technology) or just a jump into the wagon of rapid release cycle like Firefox, Chrome and others? Jorge Sol?rzano On Mon, May 12, 2014 at 4:13 PM, James R. Perkins wrote: > Yay! > > On 05/12/2014 02:27 PM, Jason Greene wrote: > > After the tag of CR2, master is now officially 9.x. Only blocker level > patches for 8.1.0.Final will be accepted for the new 8.x branch. > > > > Thanks! > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140512/e75e24b2/attachment-0001.html From jgreene at redhat.com Mon May 12 21:27:11 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Mon, 12 May 2014 21:27:11 -0400 (EDT) Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <537147A7.80107@redhat.com> Message-ID: Hi Jorge, That's a very astute observation. The answer is indeed both. The plan for WildFly is to have 6-9 month cycles and include the latest tech. So 9 will come much quicker than EE8 which is probably another 2-3 years away. We have a laundry list of major-level feature requests in jira that were on the backburner due to EE7, so this is a great opportunity to make a dent them. > On May 12, 2014, at 5:41 PM, Jorge Sol?rzano wrote: > > Is there any special feature planned that deserve the jump to 9.x (ex. pre-Java EE 8 support, major rewrite or bleeding edge technology) or just a jump into the wagon of rapid release cycle like Firefox, Chrome and others? > > > Jorge Sol?rzano > >> On Mon, May 12, 2014 at 4:13 PM, James R. Perkins wrote: >> Yay! >> >> On 05/12/2014 02:27 PM, Jason Greene wrote: >> > After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. >> > >> > Thanks! >> > >> > -- >> > Jason T. Greene >> > WildFly Lead / JBoss EAP Platform Architect >> > JBoss, a division of Red Hat >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> James R. Perkins >> JBoss by Red Hat >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140512/0aa483c1/attachment.html From jorsol at gmail.com Mon May 12 22:51:34 2014 From: jorsol at gmail.com (=?ISO-8859-1?Q?Jorge_Sol=F3rzano?=) Date: Mon, 12 May 2014 20:51:34 -0600 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <537147A7.80107@redhat.com> Message-ID: Hi Jason, This means that there will be a little sacrifice of stability.... Well every new cool feature is welcome :-) Jorge Sol?rzano http://www.jorsol.com On Mon, May 12, 2014 at 7:27 PM, Jason T. Greene wrote: > Hi Jorge, > > That's a very astute observation. The answer is indeed both. The plan for > WildFly is to have 6-9 month cycles and include the latest tech. So 9 will > come much quicker than EE8 which is probably another 2-3 years away. > > We have a laundry list of major-level feature requests in jira that were > on the backburner due to EE7, so this is a great opportunity to make a dent > them. > > On May 12, 2014, at 5:41 PM, Jorge Sol?rzano wrote: > > Is there any special feature planned that deserve the jump to 9.x (ex. > pre-Java EE 8 support, major rewrite or > b > leeding edge technology) > or just a jump into the wagon of rapid release cycle > like Firefox, Chrome and others? > > > Jorge Sol?rzano > > On Mon, May 12, 2014 at 4:13 PM, James R. Perkins wrote: > >> Yay! >> >> On 05/12/2014 02:27 PM, Jason Greene wrote: >> > After the tag of CR2, master is now officially 9.x. Only blocker level >> patches for 8.1.0.Final will be accepted for the new 8.x branch. >> > >> > Thanks! >> > >> > -- >> > Jason T. Greene >> > WildFly Lead / JBoss EAP Platform Architect >> > JBoss, a division of Red Hat >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> James R. Perkins >> JBoss by Red Hat >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140512/7ef056f3/attachment.html From brian.stansberry at redhat.com Tue May 13 00:12:19 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 12 May 2014 23:12:19 -0500 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> Message-ID: <53719BA3.8010805@redhat.com> The wildfly-next branch Kabir had been maintaining has been merged to master. On 5/12/14, 4:27 PM, Jason Greene wrote: > After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. > > Thanks! > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ttarrant at redhat.com Tue May 13 02:36:51 2014 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 13 May 2014 08:36:51 +0200 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <537147A7.80107@redhat.com> Message-ID: <5371BD83.3020707@redhat.com> Why would you think that ? A time-based release can be a very stable thing: any features that are not ready before a cut-off date can get postponed to the next release, without affecting either the schedule or stability. Tristan On 13/05/2014 04:51, Jorge Sol?rzano wrote: > Hi Jason, > > This means that there will be a little sacrifice of stability.... > > Well every new cool feature is welcome :-) > > > Jorge Sol?rzano > http://www.jorsol.com > > On Mon, May 12, 2014 at 7:27 PM, Jason T. Greene > wrote: > > Hi Jorge, > > That's a very astute observation. The answer is indeed both. The > plan for WildFly is to have 6-9 month cycles and include the > latest tech. So 9 will come much quicker than EE8 which is > probably another 2-3 years away. > > We have a laundry list of major-level feature requests in jira > that were on the backburner due to EE7, so this is a great > opportunity to make a dent them. > > On May 12, 2014, at 5:41 PM, Jorge Sol?rzano > wrote: > >> Is there any special feature planned that deserve the jump to 9.x >> (ex. pre-Java EE 8 support, major rewrite or >> b >> leeding edge technology) >> or just a jump into the wagon of rapid release cycle >> like Firefox, Chrome and others? >> >> >> Jorge Sol?rzano >> >> On Mon, May 12, 2014 at 4:13 PM, James R. Perkins >> > wrote: >> >> Yay! >> >> On 05/12/2014 02:27 PM, Jason Greene wrote: >> > After the tag of CR2, master is now officially 9.x. Only >> blocker level patches for 8.1.0.Final will be accepted for >> the new 8.x branch. >> > >> > Thanks! >> > >> > -- >> > Jason T. Greene >> > WildFly Lead / JBoss EAP Platform Architect >> > JBoss, a division of Red Hat >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> James R. Perkins >> JBoss by Red Hat >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Tue May 13 05:54:58 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 13 May 2014 11:54:58 +0200 Subject: [wildfly-dev] CR2 Released (Was: Short 8.1 CR2 on its way) In-Reply-To: References: <467DE512-4C6F-4977-8874-3F1C71A7690F@redhat.com> Message-ID: Just to remove any uncertainty. CDI 1.2 MR / Weld 2.2 upgrade was reverted and is not part of CR2 release. -- tomaz On Mon, May 12, 2014 at 11:23 PM, Jason Greene wrote: > This has now been published. After a short round of additional testing we > should be able to cut the Final in under a week. > > On May 4, 2014, at 1:56 PM, Jason Greene wrote: > > > Hi Everyone, > > > > As soon as we get a clean CI run on the latest master, I plan to cut a > 8.1 CR2 for review. We then need to get a TCK & Tools green light and we > can rerelease it as a Final (provided no blockers are uncovered). > > > > CR2 fixes some significant issues discovered on CR1, notably a JSF > memory leak and some SSL problems on Windows. CR2 also includes the Weld/CR > CDI update (1.2 MR spec release), which is why a full TCK rerun is > necessary. > > > > Thanks > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140513/1f8c6abe/attachment-0001.html From darran.lofthouse at jboss.com Tue May 13 07:33:31 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 13 May 2014 12:33:31 +0100 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <53719BA3.8010805@redhat.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <53719BA3.8010805@redhat.com> Message-ID: <5372030B.6050104@jboss.com> Have the changes made to master been ported to the new schemas in Kabir's branch? Regards, Darran Lofthouse. On 13/05/14 05:12, Brian Stansberry wrote: > The wildfly-next branch Kabir had been maintaining has been merged to > master. > > On 5/12/14, 4:27 PM, Jason Greene wrote: >> After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. >> >> Thanks! >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From brian.stansberry at redhat.com Tue May 13 07:44:57 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 13 May 2014 06:44:57 -0500 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <5372030B.6050104@jboss.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <53719BA3.8010805@redhat.com> <5372030B.6050104@jboss.com> Message-ID: <537205B9.7060507@redhat.com> I don't see anything like that in the commit history, so no. On 5/13/14, 6:33 AM, Darran Lofthouse wrote: > Have the changes made to master been ported to the new schemas in > Kabir's branch? > > Regards, > Darran Lofthouse. > > > On 13/05/14 05:12, Brian Stansberry wrote: >> The wildfly-next branch Kabir had been maintaining has been merged to >> master. >> >> On 5/12/14, 4:27 PM, Jason Greene wrote: >>> After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. >>> >>> Thanks! >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Tue May 13 07:52:43 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 13 May 2014 12:52:43 +0100 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <537205B9.7060507@redhat.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <53719BA3.8010805@redhat.com> <5372030B.6050104@jboss.com> <537205B9.7060507@redhat.com> Message-ID: <5372078B.2010205@jboss.com> Ok I will do a diff in a minute and check nothing is missing. On 13/05/14 12:44, Brian Stansberry wrote: > I don't see anything like that in the commit history, so no. > > On 5/13/14, 6:33 AM, Darran Lofthouse wrote: >> Have the changes made to master been ported to the new schemas in >> Kabir's branch? >> >> Regards, >> Darran Lofthouse. >> >> >> On 13/05/14 05:12, Brian Stansberry wrote: >>> The wildfly-next branch Kabir had been maintaining has been merged to >>> master. >>> >>> On 5/12/14, 4:27 PM, Jason Greene wrote: >>>> After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. >>>> >>>> Thanks! >>>> >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From brian.stansberry at redhat.com Tue May 13 08:03:11 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 13 May 2014 07:03:11 -0500 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <5372078B.2010205@jboss.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <53719BA3.8010805@redhat.com> <5372030B.6050104@jboss.com> <537205B9.7060507@redhat.com> <5372078B.2010205@jboss.com> Message-ID: <537209FF.8060905@redhat.com> You and Stefano both have pulled requests in Kabir's repo that presumably should be resubmitted to the main repo. On 5/13/14, 6:52 AM, Darran Lofthouse wrote: > Ok I will do a diff in a minute and check nothing is missing. > > On 13/05/14 12:44, Brian Stansberry wrote: >> I don't see anything like that in the commit history, so no. >> >> On 5/13/14, 6:33 AM, Darran Lofthouse wrote: >>> Have the changes made to master been ported to the new schemas in >>> Kabir's branch? >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> On 13/05/14 05:12, Brian Stansberry wrote: >>>> The wildfly-next branch Kabir had been maintaining has been merged to >>>> master. >>>> >>>> On 5/12/14, 4:27 PM, Jason Greene wrote: >>>>> After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> Jason T. Greene >>>>> WildFly Lead / JBoss EAP Platform Architect >>>>> JBoss, a division of Red Hat >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Tue May 13 08:19:18 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 13 May 2014 13:19:18 +0100 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <537209FF.8060905@redhat.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> <53719BA3.8010805@redhat.com> <5372030B.6050104@jboss.com> <537205B9.7060507@redhat.com> <5372078B.2010205@jboss.com> <537209FF.8060905@redhat.com> Message-ID: <53720DC6.2020607@jboss.com> Yes I will create that one again, that is the one that made me realise Kabir's branch didn't have all the WF 8 changes yet. Regards, Darran Lofthouse. On 13/05/14 13:03, Brian Stansberry wrote: > You and Stefano both have pulled requests in Kabir's repo that > presumably should be resubmitted to the main repo. > > On 5/13/14, 6:52 AM, Darran Lofthouse wrote: >> Ok I will do a diff in a minute and check nothing is missing. >> >> On 13/05/14 12:44, Brian Stansberry wrote: >>> I don't see anything like that in the commit history, so no. >>> >>> On 5/13/14, 6:33 AM, Darran Lofthouse wrote: >>>> Have the changes made to master been ported to the new schemas in >>>> Kabir's branch? >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> >>>> On 13/05/14 05:12, Brian Stansberry wrote: >>>>> The wildfly-next branch Kabir had been maintaining has been merged to >>>>> master. >>>>> >>>>> On 5/12/14, 4:27 PM, Jason Greene wrote: >>>>>> After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>> JBoss, a division of Red Hat >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From dandread at redhat.com Tue May 13 12:27:46 2014 From: dandread at redhat.com (Dimitris Andreadis) Date: Tue, 13 May 2014 18:27:46 +0200 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> Message-ID: <53724802.6@redhat.com> Hurray! On 12/05/2014 23:27, Jason Greene wrote: > After the tag of CR2, master is now officially 9.x. Only blocker level patches for 8.1.0.Final will be accepted for the new 8.x branch. > > Thanks! > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tomaz.cerar at gmail.com Tue May 13 13:35:40 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 13 May 2014 19:35:40 +0200 Subject: [wildfly-dev] Master is now 9.x! In-Reply-To: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> References: <2BE7D683-EC51-4ECC-BCB0-5CEBCDCB34C2@redhat.com> Message-ID: Yey! not we can let all the crazy ideas in :-)) On Mon, May 12, 2014 at 11:27 PM, Jason Greene wrote: > After the tag of CR2, master is now officially 9.x. Only blocker level > patches for 8.1.0.Final will be accepted for the new 8.x branch. > > Thanks! > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140513/0110ff25/attachment.html From hamedhatami2012 at gmail.com Tue May 13 16:00:51 2014 From: hamedhatami2012 at gmail.com (Hamed Hatami) Date: Wed, 14 May 2014 00:30:51 +0430 Subject: [wildfly-dev] Websocket at undertow Message-ID: Hi, I wanna manage my websocket connection or session when to connecttoserver at undertow by java client and when the server is not available , the client try to connect without exception and there is not any timeout to handle it Please help me Regards, Hamed Hatami -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140514/1ef0ff25/attachment.html From david.lloyd at redhat.com Wed May 14 09:03:25 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 14 May 2014 08:03:25 -0500 Subject: [wildfly-dev] The Big Log ID Change: https://github.com/wildfly/wildfly/pull/5906 In-Reply-To: <52FB9839.5010302@redhat.com> References: <52FB9839.5010302@redhat.com> Message-ID: <5373699D.4000005@redhat.com> FYI, Brian just merged this change. On 02/12/2014 09:50 AM, David M. Lloyd wrote: > It's right there in the topic. James and I have carried out the change > discussed in [1] and elsewhere, and have split all the old "JBAS" codes > into specific "WFLYxxx" codes. The pull request is divided into one > commit per Maven module for easier review. > > I request that every subsystem or component maintainer please review the > part of the commit that pertains to their piece, and please post > comments on the PR itself [2]. > > In addition, I want to discuss a few cases where modules are using > message bundles and loggers from neighboring modules. This is going to > become a problem when we do the distribution split-up. > > Finally, one small matter I want to sort out is that we have several > modules which use a project-specific code for IllegalArugmentExceptions > that pertain specifically to null parameters, whereas some do not use a > code for this case and just throw the exception. > > My feeling is we should either (a) don't use a code for this kind of > thing, or (b) come up with a "common" module or code space+project code > which every project can reuse, so we just have one code that universally > means "the parameter can't be null". > > [1] http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000428.html > [2] https://github.com/wildfly/wildfly/pull/5906 > -- - DML From brian.stansberry at redhat.com Wed May 14 10:21:17 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 14 May 2014 09:21:17 -0500 Subject: [wildfly-dev] The Big Log ID Change: https://github.com/wildfly/wildfly/pull/5906 In-Reply-To: <5373699D.4000005@redhat.com> References: <52FB9839.5010302@redhat.com> <5373699D.4000005@redhat.com> Message-ID: <53737BDD.3080205@redhat.com> Yes, so if you have open pull requests that involved the *Loggers/*Messages interfaces, please update them as they won't be mergeable otherwise. On 5/14/14, 8:03 AM, David M. Lloyd wrote: > FYI, Brian just merged this change. > > On 02/12/2014 09:50 AM, David M. Lloyd wrote: >> It's right there in the topic. James and I have carried out the change >> discussed in [1] and elsewhere, and have split all the old "JBAS" codes >> into specific "WFLYxxx" codes. The pull request is divided into one >> commit per Maven module for easier review. >> >> I request that every subsystem or component maintainer please review the >> part of the commit that pertains to their piece, and please post >> comments on the PR itself [2]. >> >> In addition, I want to discuss a few cases where modules are using >> message bundles and loggers from neighboring modules. This is going to >> become a problem when we do the distribution split-up. >> >> Finally, one small matter I want to sort out is that we have several >> modules which use a project-specific code for IllegalArugmentExceptions >> that pertain specifically to null parameters, whereas some do not use a >> code for this case and just throw the exception. >> >> My feeling is we should either (a) don't use a code for this kind of >> thing, or (b) come up with a "common" module or code space+project code >> which every project can reuse, so we just have one code that universally >> means "the parameter can't be null". >> >> [1] http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000428.html >> [2] https://github.com/wildfly/wildfly/pull/5906 >> > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed May 14 10:43:53 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 14 May 2014 09:43:53 -0500 Subject: [wildfly-dev] Embedding a WF instance in the CLI In-Reply-To: <5373758E.9060700@redhat.com> References: <535A78AA.6040808@redhat.com> <535A81EB.9000707@redhat.com> <535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com> <535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com> <53728668.4040007@redhat.com> <5373758E.9060700@redhat.com> Message-ID: <53738129.30709@redhat.com> Moving a thread to the dev list. This is about some prototyping I've been doing on weekends 'cause I'm bored with my regular tasks. I've been playing with direct local administration of a WF installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999. This isn't a major initiative or big priority or anything at this point. Just something I find interesting and perhaps you will too. On 5/14/14, 8:54 AM, Alexey Loubyansky wrote: > Neat :) Yes, figuring out the module path is biting everywhere. > For file system path command line arguments there is a specialized > FileSystemPathArgument. > Thanks; I'll switch to that. > > On 05/13/2014 10:54 PM, Brian Stansberry wrote: >> Copying Heiko Braun as he expressed some interest in the topic. >> >> BTW, I played with this a bit more last weekend and was able to start an >> embedded server inside the CLI easily enough. See [1] for very raw >> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then >> >> [disconnected/] embed-server >> >> There are a couple issues I see, besides the HC stuff I mentioned in my >> last message. >> >> 1) If the CLI is started in a non-modular environment via java -jar >> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into >> the jar. And then the embed-server command would need params specifying >> the location of JBOSS_HOME, possibly module path etc. But it could embed >> a server installed in any accessible filesystem location. >> >> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is >> running from a WF dist in a modular environment and the embedded server >> modules are coming from the CLI's own module path. It would be more >> effort to support embedding a server based on some other module path. >> Maybe it's no big deal; maybe it's really hard. :) >> >> 2) The console logging from the embedded server goes to stdout mixed in >> with the CLI output. Maybe that's good, maybe it's bad. >> >> [1] https://github.com/bstansberry/wildfly/tree/cli-embed >> >> On 4/28/14, 10:04 AM, Brian Stansberry wrote: >>> I was poking around at this for an hour or so over the weekend. >>> >>> The standalone case seems pretty straightforward. Seems the existing >>> embedded server API could work readily enough. The >>> org.jboss.as.embedded.StandaloneServer interface already provides a >>> ModelControllerClient. >>> >>> The domain case is much harder, as the CLI wants a HostController, not a >>> ProcessController. I'd really like this to use an in-VM client, not a >>> remote one, so I don't like having the CLI embed a PC and then the HC is >>> an external process. My thoughts of the morning are to allow inverting >>> the HC/PC relationship for this kind of usage. That is, remove >>> controlling the HC lifecycle from the charge of the PC component. CLI >>> launches HC, and then the HC creates an in-process PC-ish component (not >>> a separate process) to manage the server lifecycles. There could be all >>> sorts of problems with that; it's just the thought for the morning. >>> >>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote: >>>> Embedding the AS is the best starting point to achieve that! And more >>>> fun, I agree :) >>>> >>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote: >>>>> And to think my reason for opening the Jira was just for a common >>>>> way to >>>>> mask password inputs where java.io.Console is not available ;-) >>>>> >>>>> On 25/04/14 17:09, Brian Stansberry wrote: >>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote: >>>>>>> Wow! Indeed :) >>>>>>> >>>>>>> There could be an embedded scope - true, i.e. commands available >>>>>>> only >>>>>>> this mode, like add-user, module mgmt related stuff, etc. >>>>>> >>>>>> Those commands wouldn't need to be only in that mode though. The >>>>>> implementation of all of them would be based in the server; the >>>>>> "client" >>>>>> aspect of the CLI would just use the management interface. The >>>>>> difference between an embedded mode and what we have now would >>>>>> just be >>>>>> in how the "client" side gets its ModelControllerClient -- what we >>>>>> have >>>>>> now vs starting an embedded server and getting some sort of in-vm >>>>>> client. >>>>>> >>>>>>> But it would still mean the server/controller would have to actually >>>>>>> provide implementations of that functionality and expose it to the >>>>>>> management tools like the CLI in the embedded mode. >>>>>> >>>>>> Yep. >>>>>> >>>>>>> I like this idea as a concept - direct local management. W/o any >>>>>>> remote >>>>>>> connect/re-connect/disconnect burden. >>>>>>> >>>>>>> Extending the CLI with custom modules is on the list too. It's >>>>>>> probably >>>>>>> easier to implement at this point. >>>>>>> >>>>>> >>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related >>>>>> thread >>>>>> where I briefly get into this general area too. >>>>>> >>>>>>> Alexey >>>>>>> >>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote: >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets >>>>>>>> into >>>>>>>> some fairly fundamental brainstorming that you may find >>>>>>>> interesting. >>>>>>>> >>>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or >>>>>>>> move it >>>>>>>> into the CLI >>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT) >>>>>>>> From: Darran Lofthouse (JIRA) >>>>>>>> To: brian.stansberry at redhat.com >>>>>>>> >>>>>>>> >>>>>>>> [ >>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ] >>>>>>>> >>>>>>>> Darran Lofthouse commented on WFLY-3288: >>>>>>>> ---------------------------------------- >>>>>>>> >>>>>>>> That could be very interested, won't go into too much detail in >>>>>>>> this >>>>>>>> Jira as it is not directly related shortly I am switching to the >>>>>>>> SSL >>>>>>>> related tasks we have outstanding including the out of the box >>>>>>>> enablement we talked about in Brno - managing an embedded instance >>>>>>>> could >>>>>>>> be useful there as well to get it all op based. >>>>>>>> >>>>>>>> I can see this task may end up coming back my way combined with the >>>>>>>> other stuff ;-) >>>>>>>> >>>>>>>>> Update add-user to use AESH or move it into the CLI >>>>>>>>> --------------------------------------------------- >>>>>>>>> >>>>>>>>> Key: WFLY-3288 >>>>>>>>> URL: https://issues.jboss.org/browse/WFLY-3288 >>>>>>>>> Project: WildFly >>>>>>>>> Issue Type: Feature Request >>>>>>>>> Security Level: Public(Everyone can see) >>>>>>>>> Components: Domain Management, Scripts >>>>>>>>> Reporter: Darran Lofthouse >>>>>>>>> Fix For: Awaiting Volunteers >>>>>>>>> >>>>>>>>> >>>>>>>>> Within the add-user utility it is difficult to handle situations >>>>>>>>> where >>>>>>>>> we do not have access to a java.io.Console which is the easiest >>>>>>>>> way to >>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin >>>>>>>>> Switching to AESH would allow us to use the implementation >>>>>>>>> there to >>>>>>>>> handle this. >>>>>>>>> Alternatively it may actually make sense to make add-user a >>>>>>>>> special >>>>>>>>> mode of the CLI, we may at some point want to switch to runtime >>>>>>>>> operations being executed on the server so porting to the CLI >>>>>>>>> could be >>>>>>>>> the first step to make this possible. >>>>>>>>> Overall this is going to require further discussion so the >>>>>>>>> comments >>>>>>>>> here are just a starting point. >>>>>>>> >>>>>>>> -- >>>>>>>> This message is automatically generated by JIRA. >>>>>>>> If you think it was sent incorrectly, please contact your JIRA >>>>>>>> administrators >>>>>>>> For more information on JIRA, see: >>>>>>>> http://www.atlassian.com/software/jira >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> >> -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From mazz at redhat.com Wed May 14 10:53:40 2014 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 14 May 2014 10:53:40 -0400 (EDT) Subject: [wildfly-dev] Embedding a WF instance in the CLI In-Reply-To: <53738129.30709@redhat.com> References: <535A88CE.3010503@redhat.com> <535A8D25.5020507@redhat.com> <535A920E.5090607@redhat.com> <535E6DF8.1030507@redhat.com> <53728668.4040007@redhat.com> <5373758E.9060700@redhat.com> <53738129.30709@redhat.com> Message-ID: <1734718658.5454347.1400079220862.JavaMail.zimbra@redhat.com> How topical :) The RHQ installer could use this - just this very second I'm debugging and trying to figure out why the RHQ installer can't connect to the running app server instance to do its initial config setup - having to try to figure out what port its running on and why I can't connect is a pain. ----- Original Message ----- > Moving a thread to the dev list. > > This is about some prototyping I've been doing on weekends 'cause I'm > bored with my regular tasks. I've been playing with direct local > administration of a WF installation via the CLI without requiring a > socket-based connection. The general use case is initial setup type > activities where the user doesn't want to have to launch a WF server or > HC process and potentially have it be visible on the network. > https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a > desire some folks have expressed in being able to do configuration > without first having to edit any xml to avoid port conflicts on 9990 or > 9999. > > This isn't a major initiative or big priority or anything at this point. > Just something I find interesting and perhaps you will too. > > On 5/14/14, 8:54 AM, Alexey Loubyansky wrote: > > Neat :) Yes, figuring out the module path is biting everywhere. > > For file system path command line arguments there is a specialized > > FileSystemPathArgument. > > > > Thanks; I'll switch to that. > > > > > On 05/13/2014 10:54 PM, Brian Stansberry wrote: > >> Copying Heiko Braun as he expressed some interest in the topic. > >> > >> BTW, I played with this a bit more last weekend and was able to start an > >> embedded server inside the CLI easily enough. See [1] for very raw > >> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then > >> > >> [disconnected/] embed-server > >> > >> There are a couple issues I see, besides the HC stuff I mentioned in my > >> last message. > >> > >> 1) If the CLI is started in a non-modular environment via java -jar > >> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into > >> the jar. And then the embed-server command would need params specifying > >> the location of JBOSS_HOME, possibly module path etc. But it could embed > >> a server installed in any accessible filesystem location. > >> > >> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is > >> running from a WF dist in a modular environment and the embedded server > >> modules are coming from the CLI's own module path. It would be more > >> effort to support embedding a server based on some other module path. > >> Maybe it's no big deal; maybe it's really hard. :) > >> > >> 2) The console logging from the embedded server goes to stdout mixed in > >> with the CLI output. Maybe that's good, maybe it's bad. > >> > >> [1] https://github.com/bstansberry/wildfly/tree/cli-embed > >> > >> On 4/28/14, 10:04 AM, Brian Stansberry wrote: > >>> I was poking around at this for an hour or so over the weekend. > >>> > >>> The standalone case seems pretty straightforward. Seems the existing > >>> embedded server API could work readily enough. The > >>> org.jboss.as.embedded.StandaloneServer interface already provides a > >>> ModelControllerClient. > >>> > >>> The domain case is much harder, as the CLI wants a HostController, not a > >>> ProcessController. I'd really like this to use an in-VM client, not a > >>> remote one, so I don't like having the CLI embed a PC and then the HC is > >>> an external process. My thoughts of the morning are to allow inverting > >>> the HC/PC relationship for this kind of usage. That is, remove > >>> controlling the HC lifecycle from the charge of the PC component. CLI > >>> launches HC, and then the HC creates an in-process PC-ish component (not > >>> a separate process) to manage the server lifecycles. There could be all > >>> sorts of problems with that; it's just the thought for the morning. > >>> > >>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote: > >>>> Embedding the AS is the best starting point to achieve that! And more > >>>> fun, I agree :) > >>>> > >>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote: > >>>>> And to think my reason for opening the Jira was just for a common > >>>>> way to > >>>>> mask password inputs where java.io.Console is not available ;-) > >>>>> > >>>>> On 25/04/14 17:09, Brian Stansberry wrote: > >>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote: > >>>>>>> Wow! Indeed :) > >>>>>>> > >>>>>>> There could be an embedded scope - true, i.e. commands available > >>>>>>> only > >>>>>>> this mode, like add-user, module mgmt related stuff, etc. > >>>>>> > >>>>>> Those commands wouldn't need to be only in that mode though. The > >>>>>> implementation of all of them would be based in the server; the > >>>>>> "client" > >>>>>> aspect of the CLI would just use the management interface. The > >>>>>> difference between an embedded mode and what we have now would > >>>>>> just be > >>>>>> in how the "client" side gets its ModelControllerClient -- what we > >>>>>> have > >>>>>> now vs starting an embedded server and getting some sort of in-vm > >>>>>> client. > >>>>>> > >>>>>>> But it would still mean the server/controller would have to actually > >>>>>>> provide implementations of that functionality and expose it to the > >>>>>>> management tools like the CLI in the embedded mode. > >>>>>> > >>>>>> Yep. > >>>>>> > >>>>>>> I like this idea as a concept - direct local management. W/o any > >>>>>>> remote > >>>>>>> connect/re-connect/disconnect burden. > >>>>>>> > >>>>>>> Extending the CLI with custom modules is on the list too. It's > >>>>>>> probably > >>>>>>> easier to implement at this point. > >>>>>>> > >>>>>> > >>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related > >>>>>> thread > >>>>>> where I briefly get into this general area too. > >>>>>> > >>>>>>> Alexey > >>>>>>> > >>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote: > >>>>>>>> Hi Alexey, > >>>>>>>> > >>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets > >>>>>>>> into > >>>>>>>> some fairly fundamental brainstorming that you may find > >>>>>>>> interesting. > >>>>>>>> > >>>>>>>> > >>>>>>>> -------- Original Message -------- > >>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or > >>>>>>>> move it > >>>>>>>> into the CLI > >>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT) > >>>>>>>> From: Darran Lofthouse (JIRA) > >>>>>>>> To: brian.stansberry at redhat.com > >>>>>>>> > >>>>>>>> > >>>>>>>> [ > >>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ] > >>>>>>>> > >>>>>>>> Darran Lofthouse commented on WFLY-3288: > >>>>>>>> ---------------------------------------- > >>>>>>>> > >>>>>>>> That could be very interested, won't go into too much detail in > >>>>>>>> this > >>>>>>>> Jira as it is not directly related shortly I am switching to the > >>>>>>>> SSL > >>>>>>>> related tasks we have outstanding including the out of the box > >>>>>>>> enablement we talked about in Brno - managing an embedded instance > >>>>>>>> could > >>>>>>>> be useful there as well to get it all op based. > >>>>>>>> > >>>>>>>> I can see this task may end up coming back my way combined with the > >>>>>>>> other stuff ;-) > >>>>>>>> > >>>>>>>>> Update add-user to use AESH or move it into the CLI > >>>>>>>>> --------------------------------------------------- > >>>>>>>>> > >>>>>>>>> Key: WFLY-3288 > >>>>>>>>> URL: https://issues.jboss.org/browse/WFLY-3288 > >>>>>>>>> Project: WildFly > >>>>>>>>> Issue Type: Feature Request > >>>>>>>>> Security Level: Public(Everyone can see) > >>>>>>>>> Components: Domain Management, Scripts > >>>>>>>>> Reporter: Darran Lofthouse > >>>>>>>>> Fix For: Awaiting Volunteers > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Within the add-user utility it is difficult to handle situations > >>>>>>>>> where > >>>>>>>>> we do not have access to a java.io.Console which is the easiest > >>>>>>>>> way to > >>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin > >>>>>>>>> Switching to AESH would allow us to use the implementation > >>>>>>>>> there to > >>>>>>>>> handle this. > >>>>>>>>> Alternatively it may actually make sense to make add-user a > >>>>>>>>> special > >>>>>>>>> mode of the CLI, we may at some point want to switch to runtime > >>>>>>>>> operations being executed on the server so porting to the CLI > >>>>>>>>> could be > >>>>>>>>> the first step to make this possible. > >>>>>>>>> Overall this is going to require further discussion so the > >>>>>>>>> comments > >>>>>>>>> here are just a starting point. > >>>>>>>> > >>>>>>>> -- > >>>>>>>> This message is automatically generated by JIRA. > >>>>>>>> If you think it was sent incorrectly, please contact your JIRA > >>>>>>>> administrators > >>>>>>>> For more information on JIRA, see: > >>>>>>>> http://www.atlassian.com/software/jira > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>> > >>> > >> > >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Tue May 20 12:37:22 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 20 May 2014 17:37:22 +0100 Subject: [wildfly-dev] Dropping Qualifier from Version Number for utility artefacts Message-ID: <537B84C2.6000006@jboss.com> We have a number of additional maven projects that are pulled into WildFly where in general their predominant purpose is for use within WildFly. For these kinds of projects I am wondering if it would make more sense to drop using a version qualifier, this is compatible with our agreed scheme: - https://community.jboss.org/wiki/JBossProjectVersioning The major and minor numbers are still available for us to be able to branch off for maintenance, the micro then just becomes a tag counter. At the moment we end up in situations where components need to move from Beta to CR to Final at the appropriate time for a WildFly release even though the modules are not actually being pushed as independent projects, this creates additional work tagging and then processing the component upgrades. A couple of projects where this would make sense to me are JBoss Negotiation and JBoss SASL, both of these are tied so closely to the WildFly release that having their own qualifier does not add much. An example project where retaining the qualifier is good would be JBoss Remoting where it could easily be conceived that the chances are higher it would be used as a stand alone project. Regards, Darran Lofthouse. From darran.lofthouse at jboss.com Tue May 20 13:13:06 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 20 May 2014 18:13:06 +0100 Subject: [wildfly-dev] Failed operations over HTTP Interface : 500 Internal Server Error Message-ID: <537B8D22.7030809@jboss.com> Just pulling together some related HTTP management interface changes and I see this one is still pending: - https://issues.jboss.org/browse/WFLY-907 Are we interested in addressing this one? Personally I am not convinced we need to be going beyond just using appropriate codes from the existing set of status codes, anything else would mean HTTP users get specific information that native users do not. However one thought, could we add some form of category to the actual failure response? That way we would have something we can use to map a status code, we already have another case in the code base that checks the error code to decide which status code to use!! If we added a category to a failure clients would then also potentially be able to use this themselves. Regards, Darran Lofthouse. From brian.stansberry at redhat.com Tue May 20 13:41:08 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 20 May 2014 12:41:08 -0500 Subject: [wildfly-dev] Failed operations over HTTP Interface : 500 Internal Server Error In-Reply-To: <537B8D22.7030809@jboss.com> References: <537B8D22.7030809@jboss.com> Message-ID: <537B93B4.70504@redhat.com> On 5/20/14, 12:13 PM, Darran Lofthouse wrote: > Just pulling together some related HTTP management interface changes and > I see this one is still pending: - > > https://issues.jboss.org/browse/WFLY-907 > > Are we interested in addressing this one? > Yes. > Personally I am not convinced we need to be going beyond just using > appropriate codes from the existing set of status codes, anything else > would mean HTTP users get specific information that native users do not. > > However one thought, could we add some form of category to the actual > failure response? That way we would have something we can use to map a > status code, we already have another case in the code base that checks > the error code to decide which status code to use!! If we added a > category to a failure clients would then also potentially be able to use > this themselves. > That's fine, so long as it does not alter the structure of the response's "failure-description" field. IOW it would need to be a sibling field to "failure-description", not a child. I'm not happy at all with some of the stuff I've done using message ids in failure descriptions to decide what to do about failures, so I'd be happy to see a better mechanism. > Regards, > Darran Lofthouse. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Tue May 20 13:45:40 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 20 May 2014 18:45:40 +0100 Subject: [wildfly-dev] Failed operations over HTTP Interface : 500 Internal Server Error In-Reply-To: <537B93B4.70504@redhat.com> References: <537B8D22.7030809@jboss.com> <537B93B4.70504@redhat.com> Message-ID: <537B94C4.1090301@jboss.com> On 20/05/14 18:41, Brian Stansberry wrote: > On 5/20/14, 12:13 PM, Darran Lofthouse wrote: >> Just pulling together some related HTTP management interface changes and >> I see this one is still pending: - >> >> https://issues.jboss.org/browse/WFLY-907 >> >> Are we interested in addressing this one? >> > > Yes. > >> Personally I am not convinced we need to be going beyond just using >> appropriate codes from the existing set of status codes, anything else >> would mean HTTP users get specific information that native users do not. >> >> However one thought, could we add some form of category to the actual >> failure response? That way we would have something we can use to map a >> status code, we already have another case in the code base that checks >> the error code to decide which status code to use!! If we added a >> category to a failure clients would then also potentially be able to use >> this themselves. >> > > That's fine, so long as it does not alter the structure of the > response's "failure-description" field. IOW it would need to be a > sibling field to "failure-description", not a child. +1 that is what I was thinking, a new field so existing clients that don't query for it will not need to handle it. > I'm not happy at all with some of the stuff I've done using message ids > in failure descriptions to decide what to do about failures, so I'd be > happy to see a better mechanism. > >> Regards, >> Darran Lofthouse. >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From qutpeter at gmail.com Tue May 20 20:28:48 2014 From: qutpeter at gmail.com (Peter Cai) Date: Wed, 21 May 2014 10:28:48 +1000 Subject: [wildfly-dev] stress testing and benchmark testing Message-ID: Hi all, I recently try to find out how to stress testing and benchmark testing wildfly, and as the document ( https://docs.jboss.org/author/display/WFLY8/WildFly+Integration+Testsuite+User+Guide) states, there should be two folders called "stress" and "benchmark" respectively under testsuite folder. but I can't find them in the latest source code. I wonder if they are not available for community or the document doesn't match the actual code. Regards, Peter Cai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/e89ac207/attachment.html From stuart.w.douglas at gmail.com Tue May 20 20:36:33 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 20 May 2014 19:36:33 -0500 Subject: [wildfly-dev] stress testing and benchmark testing In-Reply-To: References: Message-ID: <39D554B1-1E33-4A85-AE9A-7BB537AB9E16@gmail.com> They used to exist, but were never used and so they were removed. Stuart Sent from my iPhone > On 20 May 2014, at 19:28, Peter Cai wrote: > > Hi all, > > I recently try to find out how to stress testing and benchmark testing wildfly, and as the document ( https://docs.jboss.org/author/display/WFLY8/WildFly+Integration+Testsuite+User+Guide) states, there should be two folders called "stress" and "benchmark" respectively under testsuite folder. > but I can't find them in the latest source code. > > I wonder if they are not available for community or the document doesn't match the actual code. > > Regards, > Peter Cai > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140520/5bc7a642/attachment.html From qutpeter at gmail.com Tue May 20 22:00:49 2014 From: qutpeter at gmail.com (Peter Cai) Date: Wed, 21 May 2014 12:00:49 +1000 Subject: [wildfly-dev] stress testing and benchmark testing In-Reply-To: <39D554B1-1E33-4A85-AE9A-7BB537AB9E16@gmail.com> References: <39D554B1-1E33-4A85-AE9A-7BB537AB9E16@gmail.com> Message-ID: Thanks Stuart, I check out tag 7.2.0.Final, the folders are there, but no testing code beneath and actually the surefire plugin was skipped. I wonder if they are available only for their commerial counterpart, i.e., EAPs. Regards, Peter C On Wed, May 21, 2014 at 10:36 AM, Stuart Douglas wrote: > They used to exist, but were never used and so they were removed. > > Stuart > > Sent from my iPhone > > On 20 May 2014, at 19:28, Peter Cai wrote: > > Hi all, > > I recently try to find out how to stress testing and benchmark testing > wildfly, and as the document ( > https://docs.jboss.org/author/display/WFLY8/WildFly+Integration+Testsuite+User+Guide) states, > there should be two folders called "stress" and "benchmark" > respectively under testsuite folder. > but I can't find them in the latest source code. > > I wonder if they are not available for community or the document doesn't > match the actual code. > > Regards, > Peter Cai > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/1a161754/attachment.html From stuart.w.douglas at gmail.com Tue May 20 22:08:00 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 20 May 2014 21:08:00 -0500 Subject: [wildfly-dev] stress testing and benchmark testing In-Reply-To: References: <39D554B1-1E33-4A85-AE9A-7BB537AB9E16@gmail.com> Message-ID: No, they were just never used. There was no secret eap only version. Stuart Sent from my iPhone > On 20 May 2014, at 21:00, Peter Cai wrote: > > Thanks Stuart, > > I check out tag 7.2.0.Final, the folders are there, but no testing code beneath and actually the surefire plugin was skipped. > I wonder if they are available only for their commerial counterpart, i.e., EAPs. > > Regards, > Peter C > > >> On Wed, May 21, 2014 at 10:36 AM, Stuart Douglas wrote: >> They used to exist, but were never used and so they were removed. >> >> Stuart >> >> Sent from my iPhone >> >>> On 20 May 2014, at 19:28, Peter Cai wrote: >>> >>> Hi all, >>> >>> I recently try to find out how to stress testing and benchmark testing wildfly, and as the document ( https://docs.jboss.org/author/display/WFLY8/WildFly+Integration+Testsuite+User+Guide) states, there should be two folders called "stress" and "benchmark" respectively under testsuite folder. >>> but I can't find them in the latest source code. >>> >>> I wonder if they are not available for community or the document doesn't match the actual code. >>> >>> Regards, >>> Peter Cai >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140520/6d033f0d/attachment.html From brian.stansberry at redhat.com Tue May 20 22:17:06 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 20 May 2014 21:17:06 -0500 Subject: [wildfly-dev] stress testing and benchmark testing In-Reply-To: References: <39D554B1-1E33-4A85-AE9A-7BB537AB9E16@gmail.com> Message-ID: <537C0CA2.90502@redhat.com> There has never been any code there, and there isn't any in the EAP code base either. We (I think it was me) created the maven modules in the very early days of AS7 development in an expectation that some day such tests would be created. None ever got written so we finally removed the modules recently. On 5/20/14, 9:00 PM, Peter Cai wrote: > Thanks Stuart, > I check out tag 7.2.0.Final, the folders are there, but no testing code > beneath and actually the surefire plugin was skipped. > I wonder if they are available only for their commerial counterpart, > i.e., EAPs. > Regards, > Peter C > > > On Wed, May 21, 2014 at 10:36 AM, Stuart Douglas > > wrote: > > They used to exist, but were never used and so they were removed. > > Stuart > > Sent from my iPhone > > On 20 May 2014, at 19:28, Peter Cai > wrote: > >> Hi all, >> I recently try to find out how to stress testing and benchmark >> testing wildfly, and as the document ( >> https://docs.jboss.org/author/display/WFLY8/WildFly+Integration+Testsuite+User+Guide) states, >> there should be two folders called "stress" and "benchmark" >> respectively under testsuite folder. >> but I can't find them in the latest source code. >> I wonder if they are not available for community or the document >> doesn't match the actual code. >> Regards, >> Peter Cai >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hanasaki at gmail.com Wed May 21 04:03:44 2014 From: hanasaki at gmail.com (hanasaki at gmail.com) Date: Wed, 21 May 2014 03:03:44 -0500 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs Message-ID: <537C5DE0.8010505@gmail.com> What are the differences between the JBoss EE6 API and the Oracle EE6 API as specified by the below maven dependencies? What issues, if any, are there in using the oracle javax api spec? Since the spec is final, wouldn't there be no differences to expect? Thank you. reference info below: javax javaee-api 6.0 compile org.jboss.spec jboss-javaee-6.0 jboss-javaee-all-6.0 3.0.2.Final From emmanuel at hibernate.org Wed May 21 04:26:05 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 21 May 2014 10:26:05 +0200 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: <537C5DE0.8010505@gmail.com> References: <537C5DE0.8010505@gmail.com> Message-ID: <20140521082605.GD12589@hibernate.org> They are binary identical as it is checked by the TCK. The reason we have our own AFAIR is that - when we work on a preview of the spec, we need to write our own anyways as the Oracle teams don't necessarily have the same timeframe - there is some license subtleties involved and we prefer to write our own from a clean room. - some APIs have actual code - and thus bugs - and we want to be able to fix them - and have. Emmanuel On Wed 2014-05-21 3:03, hanasaki at gmail.com wrote: > What are the differences between the JBoss EE6 API and the Oracle EE6 > API as specified by the below maven dependencies? What issues, if any, > are there in using the oracle javax api spec? Since the spec is final, > wouldn't there be no differences to expect? > > Thank you. > > reference info below: > > > javax > javaee-api > 6.0 > compile > > > org.jboss.spec > jboss-javaee-6.0 > jboss-javaee-all-6.0 > 3.0.2.Final > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From morgan.c.ritchie at gmail.com Wed May 21 06:52:54 2014 From: morgan.c.ritchie at gmail.com (Chris Ritchie) Date: Wed, 21 May 2014 12:52:54 +0200 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs Message-ID: The official bundles contained classes with empty methods, causing errors in some use cases, such as Arquillian tests. See this post: https://community.jboss.org/wiki/WhatsTheCauseOfThisExceptionJavalangClassFormatErrorAbsentCode >From this blog: "Sun/Oracle stripped out the code from classes that are classified as "implementations". So all the interfaces are code complete, yet any abstract class or implementation class has no code in it" For piece of mind, I would suggest using the same version of jars shipped with the application server you are using. If you are using JBoss/WildFly, stick to the jboss bundles. Cheers Chris > Message: 7 > Date: Wed, 21 May 2014 03:03:44 -0500 > From: "hanasaki at gmail.com" > Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs > To: wildfly-dev at lists.jboss.org > Message-ID: <537C5DE0.8010505 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > What are the differences between the JBoss EE6 API and the Oracle EE6 > API as specified by the below maven dependencies? What issues, if any, > are there in using the oracle javax api spec? Since the spec is final, > wouldn't there be no differences to expect? > > Thank you. > > reference info below: > > > javax > javaee-api > 6.0 > compile > > > org.jboss.spec > jboss-javaee-6.0 > jboss-javaee-all-6.0 > 3.0.2.Final > > > > ------------------------------ > > Message: 8 > Date: Wed, 21 May 2014 10:26:05 +0200 > From: Emmanuel Bernard > Subject: Re: [wildfly-dev] API differences javax EE6 vs JBoss EE6 > specs > To: "hanasaki at gmail.com" > Cc: wildfly-dev at lists.jboss.org > Message-ID: <20140521082605.GD12589 at hibernate.org> > Content-Type: text/plain; charset=us-ascii > > They are binary identical as it is checked by the TCK. > > The reason we have our own AFAIR is that > - when we work on a preview of the spec, we need to write our own > anyways as the Oracle teams don't necessarily have the same timeframe > - there is some license subtleties involved and we prefer to write our > own from a clean room. > - some APIs have actual code - and thus bugs - and we want to be able to > fix them - and have. > > Emmanuel > > On Wed 2014-05-21 3:03, hanasaki at gmail.com wrote: > > What are the differences between the JBoss EE6 API and the Oracle EE6 > > API as specified by the below maven dependencies? What issues, if any, > > are there in using the oracle javax api spec? Since the spec is final, > > wouldn't there be no differences to expect? > > > > Thank you. > > > > reference info below: > > > > > > javax > > javaee-api > > 6.0 > > compile > > > > > > org.jboss.spec > > jboss-javaee-6.0 > > jboss-javaee-all-6.0 > > 3.0.2.Final > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > ------------------------------ > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > End of wildfly-dev Digest, Vol 14, Issue 7 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/85fe038e/attachment.html From tomaz.cerar at gmail.com Wed May 21 08:00:17 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 21 May 2014 14:00:17 +0200 Subject: [wildfly-dev] Dropping Qualifier from Version Number for utility artefacts In-Reply-To: <537B84C2.6000006@jboss.com> References: <537B84C2.6000006@jboss.com> Message-ID: What would this result into in practice? Having snapshot dependencies in build as long as WildFly is in snapshot version? On Tue, May 20, 2014 at 6:37 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > We have a number of additional maven projects that are pulled into > WildFly where in general their predominant purpose is for use within > WildFly. > > For these kinds of projects I am wondering if it would make more sense > to drop using a version qualifier, this is compatible with our agreed > scheme: - > > https://community.jboss.org/wiki/JBossProjectVersioning > > The major and minor numbers are still available for us to be able to > branch off for maintenance, the micro then just becomes a tag counter. > > At the moment we end up in situations where components need to move from > Beta to CR to Final at the appropriate time for a WildFly release even > though the modules are not actually being pushed as independent > projects, this creates additional work tagging and then processing the > component upgrades. > > A couple of projects where this would make sense to me are JBoss > Negotiation and JBoss SASL, both of these are tied so closely to the > WildFly release that having their own qualifier does not add much. > > An example project where retaining the qualifier is good would be JBoss > Remoting where it could easily be conceived that the chances are higher > it would be used as a stand alone project. > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/0a0830f4/attachment.html From darran.lofthouse at jboss.com Wed May 21 08:17:46 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 21 May 2014 13:17:46 +0100 Subject: [wildfly-dev] Dropping Qualifier from Version Number for utility artefacts In-Reply-To: References: <537B84C2.6000006@jboss.com> Message-ID: <537C996A.7000808@jboss.com> On 21/05/14 13:00, Toma? Cerar wrote: > What would this result into in practice? > > Having snapshot dependencies in build as long as WildFly is in snapshot > version? No components would still be tagged as normal, we just place less emphasis on categorising them from through Alpha to Final. As it stands today sometimes a component may not be tagged as Final because it needs some time to be tested in place in WildFly (or EAP) - if testing did not reveal any issues then the component needs to be re-tagged just to set the qualifier to Final. If during testing of WildFly a critical problem was found with the sub-component a Blocker issue would be raised anyway to prevent the release of WildFly until a fix is included so having the qualifier in the modules version seems a little redundant. I am thinking this may alos have an impact on splitting up WildFly, if we are not careful we introduce the need for additional rounds of tagging just to transition release qualifiers. > > On Tue, May 20, 2014 at 6:37 PM, Darran Lofthouse > > wrote: > > We have a number of additional maven projects that are pulled into > WildFly where in general their predominant purpose is for use within > WildFly. > > For these kinds of projects I am wondering if it would make more sense > to drop using a version qualifier, this is compatible with our agreed > scheme: - > > https://community.jboss.org/wiki/JBossProjectVersioning > > The major and minor numbers are still available for us to be able to > branch off for maintenance, the micro then just becomes a tag counter. > > At the moment we end up in situations where components need to move from > Beta to CR to Final at the appropriate time for a WildFly release even > though the modules are not actually being pushed as independent > projects, this creates additional work tagging and then processing the > component upgrades. > > A couple of projects where this would make sense to me are JBoss > Negotiation and JBoss SASL, both of these are tied so closely to the > WildFly release that having their own qualifier does not add much. > > An example project where retaining the qualifier is good would be JBoss > Remoting where it could easily be conceived that the chances are higher > it would be used as a stand alone project. > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From sebastian.laskawiec at gmail.com Wed May 21 08:37:26 2014 From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=) Date: Wed, 21 May 2014 14:37:26 +0200 Subject: [wildfly-dev] JMX Console over Web Admin Console Message-ID: Hi One of our projects is based on JBoss 5.1 and we are considering migrating it to Wildfly. One of our problems is Web based JMX Console... We have pretty complicated production environment and Web based JMX console with basic Auth delegated to LDAP is the simplest solution for us. I noticed that there was a ticket opened for porting legacy JMX Console: https://issues.jboss.org/browse/WFLY-1197. However I think it would be much better idea to to have this functionality in Web Administraction console. In my opinion it would be great to have it under "Runtime" in "Status" submenu. What do you think about this idea? Best Regards -- Sebastian ?askawiec -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/b66d01ef/attachment.html From sebastian.laskawiec at gmail.com Wed May 21 08:43:31 2014 From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=) Date: Wed, 21 May 2014 14:43:31 +0200 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: References: Message-ID: Hi There is a very nice example in Adam Bien's blog: ( http://www.adam-bien.com/roller/abien/entry/trouble_with_crippled_java_ee). He tried to mock EntityManager and got java.lang.ClassFormatError, just as Chis described. You can also find pretty interesting information about Java EE specs project in Shelly McGowan's blog: https://community.jboss.org/blogs/donnamishelly/2011/04/29/jboss-java-ee-api-specs-project Best regards Sebastian 2014-05-21 12:52 GMT+02:00 Chris Ritchie : > The official bundles contained classes with empty methods, causing errors > in some use cases, such as Arquillian tests. > > See this post: > https://community.jboss.org/wiki/WhatsTheCauseOfThisExceptionJavalangClassFormatErrorAbsentCode > > From this blog: > "Sun/Oracle stripped out the code from classes that are classified as > "implementations". So all the interfaces are code complete, yet any > abstract class or implementation class has no code in it" > > For piece of mind, I would suggest using the same version of jars shipped > with the application server you are using. If you are using JBoss/WildFly, > stick to the jboss bundles. > > Cheers > > Chris > > > >> Message: 7 >> Date: Wed, 21 May 2014 03:03:44 -0500 >> From: "hanasaki at gmail.com" >> Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs >> To: wildfly-dev at lists.jboss.org >> Message-ID: <537C5DE0.8010505 at gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> >> What are the differences between the JBoss EE6 API and the Oracle EE6 >> API as specified by the below maven dependencies? What issues, if any, >> are there in using the oracle javax api spec? Since the spec is final, >> wouldn't there be no differences to expect? >> >> Thank you. >> >> reference info below: >> >> >> javax >> javaee-api >> 6.0 >> compile >> >> >> org.jboss.spec >> jboss-javaee-6.0 >> jboss-javaee-all-6.0 >> 3.0.2.Final >> >> >> >> ------------------------------ >> >> Message: 8 >> Date: Wed, 21 May 2014 10:26:05 +0200 >> From: Emmanuel Bernard >> Subject: Re: [wildfly-dev] API differences javax EE6 vs JBoss EE6 >> specs >> To: "hanasaki at gmail.com" >> Cc: wildfly-dev at lists.jboss.org >> Message-ID: <20140521082605.GD12589 at hibernate.org> >> Content-Type: text/plain; charset=us-ascii >> >> >> They are binary identical as it is checked by the TCK. >> >> The reason we have our own AFAIR is that >> - when we work on a preview of the spec, we need to write our own >> anyways as the Oracle teams don't necessarily have the same timeframe >> - there is some license subtleties involved and we prefer to write our >> own from a clean room. >> - some APIs have actual code - and thus bugs - and we want to be able to >> fix them - and have. >> >> Emmanuel >> >> On Wed 2014-05-21 3:03, hanasaki at gmail.com wrote: >> > What are the differences between the JBoss EE6 API and the Oracle EE6 >> > API as specified by the below maven dependencies? What issues, if any, >> > are there in using the oracle javax api spec? Since the spec is final, >> > wouldn't there be no differences to expect? >> > >> > Thank you. >> > >> > reference info below: >> > >> > >> > javax >> > javaee-api >> > 6.0 >> > compile >> > >> > >> > org.jboss.spec >> > jboss-javaee-6.0 >> > jboss-javaee-all-6.0 >> > 3.0.2.Final >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> ------------------------------ >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> End of wildfly-dev Digest, Vol 14, Issue 7 >> ****************************************** >> > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Sebastian ?askawiec -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/6ab3411f/attachment-0001.html From aponomarenko at rosalab.ru Wed May 21 09:18:36 2014 From: aponomarenko at rosalab.ru (Andrey Ponomarenko) Date: Wed, 21 May 2014 17:18:36 +0400 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: <537C5DE0.8010505@gmail.com> References: <537C5DE0.8010505@gmail.com> Message-ID: <537CA7AC.5010306@rosalab.ru> API changes report: http://upstream-tracker.org/downloads/compat_reports/javaee/6.0_to_jboss-6.0-3.0.2.Final/compat_report.html It's generated by https://github.com/lvc/japi-compliance-checker $> japi-compliance-checker -l javaee javaee-api-6.0.jar jboss-javaee-all-6.0-3.0.2.Final.jar hanasaki at gmail.com wrote: > What are the differences between the JBoss EE6 API and the Oracle EE6 > API as specified by the below maven dependencies? What issues, if any, > are there in using the oracle javax api spec? Since the spec is final, > wouldn't there be no differences to expect? > > Thank you. > > reference info below: > > > javax > javaee-api > 6.0 > compile > > > org.jboss.spec > jboss-javaee-6.0 > jboss-javaee-all-6.0 > 3.0.2.Final > -- Andrey Ponomarenko, NTC IT ROSA. http://www.rosalab.com/ From jason.greene at redhat.com Wed May 21 09:52:56 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 21 May 2014 08:52:56 -0500 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: <537CA7AC.5010306@rosalab.ru> References: <537C5DE0.8010505@gmail.com> <537CA7AC.5010306@rosalab.ru> Message-ID: <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> Looks that report is counting internal impl classes and all maven deps, so its not very accurate. It?s a good idea though. On May 21, 2014, at 8:18 AM, Andrey Ponomarenko wrote: > API changes report: > http://upstream-tracker.org/downloads/compat_reports/javaee/6.0_to_jboss-6.0-3.0.2.Final/compat_report.html > > It's generated by https://github.com/lvc/japi-compliance-checker > > $> japi-compliance-checker -l javaee javaee-api-6.0.jar > jboss-javaee-all-6.0-3.0.2.Final.jar > > hanasaki at gmail.com wrote: >> What are the differences between the JBoss EE6 API and the Oracle EE6 >> API as specified by the below maven dependencies? What issues, if any, >> are there in using the oracle javax api spec? Since the spec is final, >> wouldn't there be no differences to expect? >> >> Thank you. >> >> reference info below: >> >> >> javax >> javaee-api >> 6.0 >> compile >> >> >> org.jboss.spec >> jboss-javaee-6.0 >> jboss-javaee-all-6.0 >> 3.0.2.Final >> > > -- > Andrey Ponomarenko, NTC IT ROSA. > http://www.rosalab.com/ > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From aponomarenko at rosalab.ru Wed May 21 10:17:58 2014 From: aponomarenko at rosalab.ru (Andrey Ponomarenko) Date: Wed, 21 May 2014 18:17:58 +0400 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> References: <537C5DE0.8010505@gmail.com> <537CA7AC.5010306@rosalab.ru> <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> Message-ID: <537CB596.5030704@rosalab.ru> I've corrected the report: http://upstream-tracker.org/downloads/compat_reports/javaee/6.0_to_jboss-6.0-3.0.2.Final/compat_report_pub.html Added --skip-internal="\A(java_cup|org)" cmd option in order to check javax package only. Jason Greene wrote: > Looks that report is counting internal impl classes and all maven deps, so its not very accurate. It?s a good idea though. > > On May 21, 2014, at 8:18 AM, Andrey Ponomarenko wrote: > >> API changes report: >> http://upstream-tracker.org/downloads/compat_reports/javaee/6.0_to_jboss-6.0-3.0.2.Final/compat_report.html >> >> It's generated by https://github.com/lvc/japi-compliance-checker >> >> $> japi-compliance-checker -l javaee javaee-api-6.0.jar >> jboss-javaee-all-6.0-3.0.2.Final.jar >> >> hanasaki at gmail.com wrote: >>> What are the differences between the JBoss EE6 API and the Oracle EE6 >>> API as specified by the below maven dependencies? What issues, if any, >>> are there in using the oracle javax api spec? Since the spec is final, >>> wouldn't there be no differences to expect? >>> >>> Thank you. >>> >>> reference info below: >>> >>> >>> javax >>> javaee-api >>> 6.0 >>> compile >>> >>> >>> org.jboss.spec >>> jboss-javaee-6.0 >>> jboss-javaee-all-6.0 >>> 3.0.2.Final >>> -- Andrey Ponomarenko, NTC IT ROSA. http://www.rosalab.com/ From tomaz.cerar at gmail.com Wed May 21 10:25:47 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 21 May 2014 16:25:47 +0200 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: <537CB596.5030704@rosalab.ru> References: <537C5DE0.8010505@gmail.com> <537CA7AC.5010306@rosalab.ru> <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> <537CB596.5030704@rosalab.ru> Message-ID: Question is what is proper or reference, for our Jars we are sure they pass Java EE6/7 TCK signature tests (which tests mostly what you are comparing) question is from where id javaee.jar you are using come frome, and does it also pass TCK signature tests. On Wed, May 21, 2014 at 4:17 PM, Andrey Ponomarenko wrote: > I've corrected the report: > > http://upstream-tracker.org/downloads/compat_reports/javaee/6.0_to_jboss-6.0-3.0.2.Final/compat_report_pub.html > > Added --skip-internal="\A(java_cup|org)" cmd option in order to check > javax package only. > > Jason Greene wrote: > > Looks that report is counting internal impl classes and all maven deps, > so its not very accurate. It?s a good idea though. > > > > On May 21, 2014, at 8:18 AM, Andrey Ponomarenko > wrote: > > > >> API changes report: > >> > http://upstream-tracker.org/downloads/compat_reports/javaee/6.0_to_jboss-6.0-3.0.2.Final/compat_report.html > >> > >> It's generated by https://github.com/lvc/japi-compliance-checker > >> > >> $> japi-compliance-checker -l javaee javaee-api-6.0.jar > >> jboss-javaee-all-6.0-3.0.2.Final.jar > >> > >> hanasaki at gmail.com wrote: > >>> What are the differences between the JBoss EE6 API and the Oracle EE6 > >>> API as specified by the below maven dependencies? What issues, if any, > >>> are there in using the oracle javax api spec? Since the spec is final, > >>> wouldn't there be no differences to expect? > >>> > >>> Thank you. > >>> > >>> reference info below: > >>> > >>> > >>> javax > >>> javaee-api > >>> 6.0 > >>> compile > >>> > >>> > >>> org.jboss.spec > >>> jboss-javaee-6.0 > >>> jboss-javaee-all-6.0 > >>> 3.0.2.Final > >>> > > -- > Andrey Ponomarenko, NTC IT ROSA. > http://www.rosalab.com/ > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/e8d0d129/attachment.html From aponomarenko at rosalab.ru Wed May 21 10:27:21 2014 From: aponomarenko at rosalab.ru (Andrey Ponomarenko) Date: Wed, 21 May 2014 18:27:21 +0400 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: References: <537C5DE0.8010505@gmail.com> <537CA7AC.5010306@rosalab.ru> <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> <537CB596.5030704@rosalab.ru> Message-ID: <537CB7C9.4040305@rosalab.ru> It's from http://download.java.net/maven/2/javax/javaee-api/6.0/javaee-api-6.0.jar Toma? Cerar wrote: > Question is what is proper or reference, for our Jars we are sure they pass > Java EE6/7 TCK signature tests (which tests mostly what you are comparing) > > question is from where id javaee.jar you are using come frome, and does it > also pass TCK signature tests. > > > On Wed, May 21, 2014 at 4:17 PM, Andrey Ponomarenko > wrote: >> I've corrected the report: >> >> http://upstream-tracker.org/downloads/compat_reports/javaee/6.0_to_jboss-6.0-3.0.2.Final/compat_report_pub.html >> >> Added --skip-internal="\A(java_cup|org)" cmd option in order to check >> javax package only. >> >> Jason Greene wrote: >>> Looks that report is counting internal impl classes and all maven deps, >> so its not very accurate. It?s a good idea though. >>> On May 21, 2014, at 8:18 AM, Andrey Ponomarenko >> wrote: >>>> API changes report: >>>> >> http://upstream-tracker.org/downloads/compat_reports/javaee/6.0_to_jboss-6.0-3.0.2.Final/compat_report.html >>>> It's generated by https://github.com/lvc/japi-compliance-checker >>>> >>>> $> japi-compliance-checker -l javaee javaee-api-6.0.jar >>>> jboss-javaee-all-6.0-3.0.2.Final.jar >>>> >>>> hanasaki at gmail.com wrote: >>>>> What are the differences between the JBoss EE6 API and the Oracle EE6 >>>>> API as specified by the below maven dependencies? What issues, if any, >>>>> are there in using the oracle javax api spec? Since the spec is final, >>>>> wouldn't there be no differences to expect? >>>>> >>>>> Thank you. >>>>> >>>>> reference info below: >>>>> >>>>> >>>>> javax >>>>> javaee-api >>>>> 6.0 >>>>> compile >>>>> >>>>> >>>>> org.jboss.spec >>>>> jboss-javaee-6.0 >>>>> jboss-javaee-all-6.0 >>>>> 3.0.2.Final >>>>> >>>>> -- Andrey Ponomarenko, NTC IT ROSA. http://www.rosalab.com/ From tomaz.cerar at gmail.com Wed May 21 11:01:14 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 21 May 2014 17:01:14 +0200 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: <537CB7C9.4040305@rosalab.ru> References: <537C5DE0.8010505@gmail.com> <537CA7AC.5010306@rosalab.ru> <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> <537CB596.5030704@rosalab.ru> <537CB7C9.4040305@rosalab.ru> Message-ID: On Wed, May 21, 2014 at 4:27 PM, Andrey Ponomarenko wrote: > http://download.java.net/maven/2/javax/j > I know where it is from, but question is, is it official javaee artifact?, AFAIK only with JEE7 did this became mandatory as part of JSR for example just compare http://repo1.maven.org/maven2/javax/javaee-api/7.0/javaee-api-7.0.pom vs http://repo1.maven.org/maven2/javax/javaee-api/6.0/javaee-api-6.0.pom to see what I mean, tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/1e77b91f/attachment.html From smcgowan at redhat.com Wed May 21 11:16:47 2014 From: smcgowan at redhat.com (Shelly McGowan) Date: Wed, 21 May 2014 11:16:47 -0400 (EDT) Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: References: <537C5DE0.8010505@gmail.com> <537CA7AC.5010306@rosalab.ru> <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> <537CB596.5030704@rosalab.ru> <537CB7C9.4040305@rosalab.ru> Message-ID: <2104056894.10693844.1400685407680.JavaMail.zimbra@redhat.com> Tomaz, Those are provided by reference implementation. We started the Java EE Spec API project a while ago for the reasons listed here: https://github.com/jboss/jboss-javaee-specs/blob/master/README.md These APIs were later promoted with the WELD archetypes[1] as the recommended approach due to a few issues with the javaee-api JAR from GlassFish repository; specifically, - It's a shaded JAR, so you have no idea what it actually bundles - The code is stripped out of all the method bodies, so you get an Absent Code exception if you try to touch any of the classes Shelly [1]https://community.jboss.org/thread/179735 ----- Original Message ----- From: "Toma? Cerar" To: "Andrey Ponomarenko" Cc: wildfly-dev at lists.jboss.org Sent: Wednesday, May 21, 2014 11:01:14 AM Subject: Re: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs On Wed, May 21, 2014 at 4:27 PM, Andrey Ponomarenko < aponomarenko at rosalab.ru > wrote: http://download.java.net/ maven/2/javax/j I know where it is from, but question is, is it official javaee artifact?, AFAIK only with JEE7 did this became mandatory as part of JSR for example just compare http://repo1.maven.org/maven2/javax/javaee-api/7.0/javaee-api-7.0.pom vs http://repo1.maven.org/maven2/javax/javaee-api/6.0/javaee-api-6.0.pom to see what I mean, tomaz _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Wed May 21 11:28:45 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 21 May 2014 17:28:45 +0200 Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: <2104056894.10693844.1400685407680.JavaMail.zimbra@redhat.com> References: <537C5DE0.8010505@gmail.com> <537CA7AC.5010306@rosalab.ru> <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> <537CB596.5030704@rosalab.ru> <537CB7C9.4040305@rosalab.ru> <2104056894.10693844.1400685407680.JavaMail.zimbra@redhat.com> Message-ID: Agreed, that is why I am saying that javaee6 jar is not really representative, what was done with javaee7 one is completely different story. On Wed, May 21, 2014 at 5:16 PM, Shelly McGowan wrote: > > > Tomaz, > > Those are provided by reference implementation. We started the Java EE > Spec API project a while ago for the reasons listed here: > https://github.com/jboss/jboss-javaee-specs/blob/master/README.md > > These APIs were later promoted with the WELD archetypes[1] as the > recommended approach due to a few issues with the javaee-api JAR from > GlassFish repository; specifically, > > - It's a shaded JAR, so you have no idea what it actually bundles > - The code is stripped out of all the method bodies, so you get an Absent > Code exception if you try to touch any of the classes > > > Shelly > > > [1]https://community.jboss.org/thread/179735 > > > ----- Original Message ----- > From: "Toma? Cerar" > To: "Andrey Ponomarenko" > Cc: wildfly-dev at lists.jboss.org > Sent: Wednesday, May 21, 2014 11:01:14 AM > Subject: Re: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs > > > On Wed, May 21, 2014 at 4:27 PM, Andrey Ponomarenko < > aponomarenko at rosalab.ru > wrote: > > > > http://download.java.net/ maven/2/javax/j > > > I know where it is from, but question is, is it official javaee artifact?, > AFAIK only with JEE7 did this became mandatory as part of JSR > for example just compare > > http://repo1.maven.org/maven2/javax/javaee-api/7.0/javaee-api-7.0.pom > vs > http://repo1.maven.org/maven2/javax/javaee-api/6.0/javaee-api-6.0.pom > > to see what I mean, > tomaz > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/7ded6e9d/attachment.html From jgreene at redhat.com Wed May 21 11:59:28 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Wed, 21 May 2014 11:59:28 -0400 (EDT) Subject: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs In-Reply-To: References: <537C5DE0.8010505@gmail.com> <537CA7AC.5010306@rosalab.ru> <8C7CDA12-E17D-4898-AEA7-B9C77270A7EB@redhat.com> <537CB596.5030704@rosalab.ru> <537CB7C9.4040305@rosalab.ru> <2104056894.10693844.1400685407680.JavaMail.zimbra@redhat.com> Message-ID: <9ACB41CC-9CEF-42AD-B573-81FC91ACA23E@redhat.com> This type of report is a good idea though because it's always going to e more thorough than the TCK signature tests will be. The hard part though is eliminating all of the false alarms so that it's useful. Cases that can trip it up: - Public classes which are not directly exposed by the API but simply used to by the API (Util classes, factory impls etc) - Java SE classes which likely trip up the report because the Java EE version is more recent and therefore requires endorsed or special class loading - Vendor Implementation Hooks. These are allowed to exist and in some cases are even required. This is why one should always prefer the API shipped by the container they are using. - Bug Fixes / MR releases might report slight changes to method signatures or additional methods. Per Tomaz's point, a focus on EE7 is better but if someone wants to volunteer time on discovering EE6 compliance issues we would certainly address any issues discovered. Of course patches would be even better :) -Jason Sent from my iPhone > On May 21, 2014, at 10:29 AM, Toma? Cerar wrote: > > Agreed, that is why I am saying that javaee6 jar is not really representative, what was done with javaee7 one is completely different story. > > >> On Wed, May 21, 2014 at 5:16 PM, Shelly McGowan wrote: >> >> >> Tomaz, >> >> Those are provided by reference implementation. We started the Java EE Spec API project a while ago for the reasons listed here: >> https://github.com/jboss/jboss-javaee-specs/blob/master/README.md >> >> These APIs were later promoted with the WELD archetypes[1] as the recommended approach due to a few issues with the javaee-api JAR from GlassFish repository; specifically, >> >> - It's a shaded JAR, so you have no idea what it actually bundles >> - The code is stripped out of all the method bodies, so you get an Absent Code exception if you try to touch any of the classes >> >> >> Shelly >> >> >> [1]https://community.jboss.org/thread/179735 >> >> >> ----- Original Message ----- >> From: "Toma? Cerar" >> To: "Andrey Ponomarenko" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Wednesday, May 21, 2014 11:01:14 AM >> Subject: Re: [wildfly-dev] API differences javax EE6 vs JBoss EE6 specs >> >> >> On Wed, May 21, 2014 at 4:27 PM, Andrey Ponomarenko < aponomarenko at rosalab.ru > wrote: >> >> >> >> http://download.java.net/ maven/2/javax/j >> >> >> I know where it is from, but question is, is it official javaee artifact?, AFAIK only with JEE7 did this became mandatory as part of JSR >> for example just compare >> >> http://repo1.maven.org/maven2/javax/javaee-api/7.0/javaee-api-7.0.pom >> vs >> http://repo1.maven.org/maven2/javax/javaee-api/6.0/javaee-api-6.0.pom >> >> to see what I mean, >> tomaz >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140521/d5ded5af/attachment.html From brian.stansberry at redhat.com Wed May 21 21:23:53 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 21 May 2014 20:23:53 -0500 Subject: [wildfly-dev] JMX Console over Web Admin Console In-Reply-To: References: Message-ID: <537D51A9.7090803@redhat.com> I agree that if we exposed the mbean server over HTTP that it should be via a context on our HTTP management interface. Either that or expose mbeans as part of our standard management resource tree. That would make integration in the web console much more practical. I don't see us ever bringing back the AS5-style jmx-console.war that runs on port 8080 as part of the WildFly distribution. That would introduce a requirement for EE into our management infrastructure, and we won't do that. Management is part of WildFly core, and WildFly core does not require EE. If the Servlet-based jmx-console.war code linked from WFLY-1197 gets further developed, I see it as a community effort for people who want to install that on their own, not as something we'd distribute as part of WildFly itself. On 5/21/14, 7:37 AM, Sebastian ?askawiec wrote: > Hi > > One of our projects is based on JBoss 5.1 and we are considering > migrating it to Wildfly. One of our problems is Web based JMX Console... > We have pretty complicated production environment and Web based JMX > console with basic Auth delegated to LDAP is the simplest solution for us. > > I noticed that there was a ticket opened for porting legacy JMX Console: > https://issues.jboss.org/browse/WFLY-1197. > However I think it would be much better idea to to have this > functionality in Web Administraction console. In my opinion it would be > great to have it under "Runtime" in "Status" submenu. > > What do you think about this idea? > > Best Regards > -- > Sebastian ?askawiec > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Thu May 22 08:52:05 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 22 May 2014 13:52:05 +0100 Subject: [wildfly-dev] Updates to HTTP Management Interface Configuration Message-ID: <537DF2F5.6050809@jboss.com> This is still very much work in progress but I just wanted to share some of my work capturing configuration requirements for the HTTP management interface so far: - https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration I am capturing all current requests for flexibility regarding the management interface although this does not mean they will all be implemented at once, instead it is so we know where the configuration can live if an when these capabilities are added. I am still thinking about this but I may remove references to the security realms and instead reference security/ssl policies - initial policies would still be based around the existing realms but the policies would enable us to migrate to subsequent security solutions without affecting the configuration of the interface. Now would also be a very good time to speak up if you have any additional items where you think it would nice if we could configure on the http management interface. Regards, Darran Lofthouse. From rory.odonnell at oracle.com Fri May 23 03:57:49 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Fri, 23 May 2014 08:57:49 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b13, JDK 8u20 b15 and JDK 7u60 b15 are available on java.net Message-ID: <537EFF7D.7080607@oracle.com> Hi Guys, Early Access builds for JDK 9 b13 , JDK 8u20 b15 and JDK 7u60 b15 are available on java.net. As we enter the later phases of development for JDK 7u60 & JDK 8u20 , please log any show stoppers as soon as possible. Hi Tomaz, Regarding the regression in JDK 8 , Can you please log a bug at bugs.sun.com and let us know the incident number, we will chase it up on this end. Rgds, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140523/6eb06d72/attachment-0001.html From arun.gupta at gmail.com Tue May 27 18:06:13 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 27 May 2014 15:06:13 -0700 Subject: [wildfly-dev] Port 9999 in domain.xml Message-ID: domain.xml has the following excerpt: The port should be changed to 9990 ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From arun.gupta at gmail.com Tue May 27 18:39:27 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 27 May 2014 15:39:27 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave Message-ID: Trying to following the instructions at: https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto This shows how to setup a 2-instance cluster in master/slave where master is on my laptop and slave is on a Raspi. Couple of questions ... 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ? FTR it only works with 9999, not with 9990. Domain Controller shows the message: [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host Controller Service Threads - 28) JBAS010918: Registered remote slave host "slave", WildFly 8.1.0.CR2 "Kenny" 2). Master is throwing the following exception: 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:server-one' [Server:server-one] Error occurred during initialization of VM [Server:server-one] Server VM is only supported on ARMv7+ VFP 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' finished with an exit status of 1 [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering server server-one [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010922: Starting server server-two 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) JBAS012006: Failed to send data bytes to process 'Server:server-one' input stream: java.io.IOException: Stream closed at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) [rt.jar:1.7.0_40] at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) [rt.jar:1.7.0_40] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) [rt.jar:1.7.0_40] at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) [rt.jar:1.7.0_40] at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] 22:15:26,573 ERROR [org.jboss.as.protocol.connection] (ProcessController-threads - 3) JBAS016610: Failed to read a message: java.io.IOException: Stream closed at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) [rt.jar:1.7.0_40] at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) [rt.jar:1.7.0_40] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) [rt.jar:1.7.0_40] at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) [rt.jar:1.7.0_40] at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] Same error for server-two as well. Trying to explicitly start server-three on slave gives the same error. This is all using 8.1 CR2. Any idea what might be wrong ? Thanks Aru -- http://blog.arungupta.me http://twitter.com/arungupta From kabir.khan at jboss.com Tue May 27 19:01:19 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 28 May 2014 00:01:19 +0100 Subject: [wildfly-dev] Port 9999 in domain.xml In-Reply-To: References: Message-ID: <35F9ACB0-BA6C-4AEC-8127-B6065EDE6542@jboss.com> On 27 May 2014, at 23:06, Arun Gupta wrote: > domain.xml has the following excerpt: host.xml? :-) > > > > port="${jboss.management.native.port:9999}"/> > > > The port should be changed to 9990 ? No, that is handled by the next interface The native-interface one is there so that legacy HCs which don?t have the http-remoting protocol can connect back to the domain controller. host-slave.xml which is used on the slaves does not have the native interface enabled since it will only be connecting to a DC of the same version or newer. > > Arun > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Tue May 27 19:13:33 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 28 May 2014 00:13:33 +0100 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: Message-ID: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> On 27 May 2014, at 23:39, Arun Gupta wrote: > Trying to following the instructions at: > > https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto > > This shows how to setup a 2-instance cluster in master/slave where > master is on my laptop and slave is on a Raspi. Couple of questions > ... > > 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ? > > > > > > FTR it only works with 9999, not with 9990. > > Domain Controller shows the message: > > [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host > Controller Service Threads - 28) JBAS010918: Registered remote slave > host "slave", WildFly 8.1.0.CR2 ?Kenny? It looks like we hardcode the old ?remote://? protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the element take a ?protocol? attribute? > > > 2). Master is throwing the following exception: > > 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] > (ProcessController-threads - 3) JBAS012017: Starting process > 'Server:server-one' > [Server:server-one] Error occurred during initialization of VM > [Server:server-one] Server VM is only supported on ARMv7+ VFP This ^^ seems to be the real error. Try removing ?-server? in the jvm-options. > 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] > (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' > finished with an exit status of 1 > [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] > (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering > server server-one > [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] > (Controller Boot Thread) JBAS010922: Starting server server-two > 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] > (ProcessController-threads - 3) JBAS012006: Failed to send data bytes > to process 'Server:server-one' input stream: java.io.IOException: > Stream closed > at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) > [rt.jar:1.7.0_40] > at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > [rt.jar:1.7.0_40] > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > [rt.jar:1.7.0_40] > at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) > [rt.jar:1.7.0_40] > at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > 22:15:26,573 ERROR [org.jboss.as.protocol.connection] > (ProcessController-threads - 3) JBAS016610: Failed to read a message: > java.io.IOException: Stream closed > at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) > [rt.jar:1.7.0_40] > at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > [rt.jar:1.7.0_40] > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > [rt.jar:1.7.0_40] > at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) > [rt.jar:1.7.0_40] > at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) > [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > > Same error for server-two as well. > > Trying to explicitly start server-three on slave gives the same error. > > This is all using 8.1 CR2. > > Any idea what might be wrong ? > > Thanks > Aru > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From arun.gupta at gmail.com Tue May 27 19:27:12 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 27 May 2014 16:27:12 -0700 Subject: [wildfly-dev] Port 9999 in domain.xml In-Reply-To: <35F9ACB0-BA6C-4AEC-8127-B6065EDE6542@jboss.com> References: <35F9ACB0-BA6C-4AEC-8127-B6065EDE6542@jboss.com> Message-ID: On Tue, May 27, 2014 at 4:01 PM, Kabir Khan wrote: > > On 27 May 2014, at 23:06, Arun Gupta wrote: > >> domain.xml has the following excerpt: > host.xml? :-) >> Yes :-) >> >> >> > port="${jboss.management.native.port:9999}"/> >> >> >> The port should be changed to 9990 ? > > No, that is handled by the next interface > > > > > > The native-interface one is there so that legacy HCs which don?t have the http-remoting protocol can connect back to the domain controller. host-slave.xml which is used on the slaves does not have the native interface enabled since it will only be connecting to a DC of the same version or newer. > https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto still refer to JBoss AS 7. Where can I find the latest WildFly instructions that use host-slave.xml ? Arun >> >> Arun >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- http://blog.arungupta.me http://twitter.com/arungupta From arun.gupta at gmail.com Tue May 27 20:02:52 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 27 May 2014 17:02:52 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> Message-ID: On Tue, May 27, 2014 at 4:13 PM, Kabir Khan wrote: > > On 27 May 2014, at 23:39, Arun Gupta wrote: > >> Trying to following the instructions at: >> >> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >> >> This shows how to setup a 2-instance cluster in master/slave where >> master is on my laptop and slave is on a Raspi. Couple of questions >> ... >> >> 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ? >> >> >> >> >> >> FTR it only works with 9999, not with 9990. >> >> Domain Controller shows the message: >> >> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >> Controller Service Threads - 28) JBAS010918: Registered remote slave >> host "slave", WildFly 8.1.0.CR2 ?Kenny? > It looks like we hardcode the old ?remote://? protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the element take a ?protocol? attribute? >> >> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. >> 2). Master is throwing the following exception: >> >> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >> (ProcessController-threads - 3) JBAS012017: Starting process >> 'Server:server-one' >> [Server:server-one] Error occurred during initialization of VM >> [Server:server-one] Server VM is only supported on ARMv7+ VFP > This ^^ seems to be the real error. Try removing ?-server? in the jvm-options. I removed -server from domain.sh, didn't realize its hardcoded in host.xml. It worked after commenting in host.xml. Is that a bug as well ? Arun > >> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >> (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' >> finished with an exit status of 1 >> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >> server server-one >> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >> (Controller Boot Thread) JBAS010922: Starting server server-two >> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >> (ProcessController-threads - 3) JBAS012006: Failed to send data bytes >> to process 'Server:server-one' input stream: java.io.IOException: >> Stream closed >> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >> [rt.jar:1.7.0_40] >> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >> [rt.jar:1.7.0_40] >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >> [rt.jar:1.7.0_40] >> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >> [rt.jar:1.7.0_40] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_40] >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_40] >> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >> (ProcessController-threads - 3) JBAS016610: Failed to read a message: >> java.io.IOException: Stream closed >> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >> [rt.jar:1.7.0_40] >> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >> [rt.jar:1.7.0_40] >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >> [rt.jar:1.7.0_40] >> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >> [rt.jar:1.7.0_40] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_40] >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_40] >> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >> >> Same error for server-two as well. >> >> Trying to explicitly start server-three on slave gives the same error. >> >> This is all using 8.1 CR2. >> >> Any idea what might be wrong ? >> >> Thanks >> Aru >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- http://blog.arungupta.me http://twitter.com/arungupta From arun.gupta at gmail.com Tue May 27 22:49:29 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 27 May 2014 19:49:29 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> Message-ID: I think master/slave is now configured on two nodes, Domain Controller shows the following message: [Host Controller] 16:34:18,888 INFO [org.jboss.as.domain] (Host Controller Service Threads - 32) JBAS010918: Registered remote slave host "slave", WildFly 8.1.0.CR2 "Kenny" Deployed/enabled a simple app and assigned to other-server-group and saw the log message: [Host Controller] 18:57:19,508 INFO [org.jboss.as.repository] (XNIO-1 task-9) JBAS014900: Content added at location /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content The app is now accessible on master and slave on :8330. By default, if an app is deployed to other-server-group on Domain Controller, does it get deployed to all servers in that server-group ? If the two nodes are on the same host then session replication work. This is the first time I've configured nodes on two different hosts and can't get session replication to work. That is, session attributes added to the application on one node (master) are not visible on the other node (slave). What configuration am I missing ? Arun On Tue, May 27, 2014 at 5:02 PM, Arun Gupta wrote: > On Tue, May 27, 2014 at 4:13 PM, Kabir Khan wrote: >> >> On 27 May 2014, at 23:39, Arun Gupta wrote: >> >>> Trying to following the instructions at: >>> >>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >>> >>> This shows how to setup a 2-instance cluster in master/slave where >>> master is on my laptop and slave is on a Raspi. Couple of questions >>> ... >>> >>> 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ? >>> >>> >>> >>> >>> >>> FTR it only works with 9999, not with 9990. >>> >>> Domain Controller shows the message: >>> >>> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >>> Controller Service Threads - 28) JBAS010918: Registered remote slave >>> host "slave", WildFly 8.1.0.CR2 ?Kenny? >> It looks like we hardcode the old ?remote://? protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the element take a ?protocol? attribute? >>> >>> > > Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. > >>> 2). Master is throwing the following exception: >>> >>> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >>> (ProcessController-threads - 3) JBAS012017: Starting process >>> 'Server:server-one' >>> [Server:server-one] Error occurred during initialization of VM >>> [Server:server-one] Server VM is only supported on ARMv7+ VFP >> This ^^ seems to be the real error. Try removing ?-server? in the jvm-options. > > I removed -server from domain.sh, didn't realize its hardcoded in > host.xml. It worked after commenting in host.xml. Is that a bug as > well ? > > Arun > >> >>> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >>> (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' >>> finished with an exit status of 1 >>> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >>> server server-one >>> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >>> (Controller Boot Thread) JBAS010922: Starting server server-two >>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >>> (ProcessController-threads - 3) JBAS012006: Failed to send data bytes >>> to process 'Server:server-one' input stream: java.io.IOException: >>> Stream closed >>> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>> [rt.jar:1.7.0_40] >>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>> [rt.jar:1.7.0_40] >>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>> [rt.jar:1.7.0_40] >>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>> [rt.jar:1.7.0_40] >>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> [rt.jar:1.7.0_40] >>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> [rt.jar:1.7.0_40] >>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >>> (ProcessController-threads - 3) JBAS016610: Failed to read a message: >>> java.io.IOException: Stream closed >>> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>> [rt.jar:1.7.0_40] >>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>> [rt.jar:1.7.0_40] >>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>> [rt.jar:1.7.0_40] >>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>> [rt.jar:1.7.0_40] >>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> [rt.jar:1.7.0_40] >>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> [rt.jar:1.7.0_40] >>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>> >>> Same error for server-two as well. >>> >>> Trying to explicitly start server-three on slave gives the same error. >>> >>> This is all using 8.1 CR2. >>> >>> Any idea what might be wrong ? >>> >>> Thanks >>> Aru >>> >>> -- >>> http://blog.arungupta.me >>> http://twitter.com/arungupta >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta -- http://blog.arungupta.me http://twitter.com/arungupta From kabir.khan at jboss.com Wed May 28 04:33:22 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 28 May 2014 09:33:22 +0100 Subject: [wildfly-dev] Port 9999 in domain.xml In-Reply-To: References: <35F9ACB0-BA6C-4AEC-8127-B6065EDE6542@jboss.com> Message-ID: On 28 May 2014, at 00:27, Arun Gupta wrote: > On Tue, May 27, 2014 at 4:01 PM, Kabir Khan wrote: >> >> On 27 May 2014, at 23:06, Arun Gupta wrote: >> >>> domain.xml has the following excerpt: >> host.xml? :-) >>> > Yes :-) > >>> >>> >>> >> port="${jboss.management.native.port:9999}"/> >>> >>> >>> The port should be changed to 9990 ? >> >> No, that is handled by the next interface >> >> >> >> >> >> The native-interface one is there so that legacy HCs which don?t have the http-remoting protocol can connect back to the domain controller. host-slave.xml which is used on the slaves does not have the native interface enabled since it will only be connecting to a DC of the same version or newer. >> > > https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto > still refer to JBoss AS 7. Where can I find the latest WildFly > instructions that use host-slave.xml ? You can update the documentation to say WildFly. > > Arun > >>> >>> Arun >>> >>> >>> -- >>> http://blog.arungupta.me >>> http://twitter.com/arungupta >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta From kabir.khan at jboss.com Wed May 28 04:39:12 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 28 May 2014 09:39:12 +0100 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> Message-ID: On 28 May 2014, at 03:49, Arun Gupta wrote: > I think master/slave is now configured on two nodes, Domain Controller > shows the following message: > > [Host Controller] 16:34:18,888 INFO [org.jboss.as.domain] (Host > Controller Service Threads - 32) JBAS010918: Registered remote slave > host "slave", WildFly 8.1.0.CR2 "Kenny" > > Deployed/enabled a simple app and assigned to other-server-group and > saw the log message: > > [Host Controller] 18:57:19,508 INFO [org.jboss.as.repository] (XNIO-1 > task-9) JBAS014900: Content added at location > /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content > > The app is now accessible on master and slave on :8330. > > By default, if an app is deployed to other-server-group on Domain > Controller, does it get deployed to all servers in that server-group ? Yes, and if you bring up more hosts with servers in that server group, or more servers in that group on an existing host, the app gets deployed to those as well. > > If the two nodes are on the same host then session replication work. > This is the first time I've configured nodes on two different hosts > and can't get session replication to work. That is, session attributes > added to the application on one node (master) are not visible on the > other node (slave). What configuration am I missing ? I?m not so familiar with clustering so I am not sure. Richard? > > Arun > > On Tue, May 27, 2014 at 5:02 PM, Arun Gupta wrote: >> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan wrote: >>> >>> On 27 May 2014, at 23:39, Arun Gupta wrote: >>> >>>> Trying to following the instructions at: >>>> >>>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >>>> >>>> This shows how to setup a 2-instance cluster in master/slave where >>>> master is on my laptop and slave is on a Raspi. Couple of questions >>>> ... >>>> >>>> 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ? >>>> >>>> >>>> >>>> >>>> >>>> FTR it only works with 9999, not with 9990. >>>> >>>> Domain Controller shows the message: >>>> >>>> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >>>> Controller Service Threads - 28) JBAS010918: Registered remote slave >>>> host "slave", WildFly 8.1.0.CR2 ?Kenny? >>> It looks like we hardcode the old ?remote://? protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the element take a ?protocol? attribute? >>>> >>>> >> >> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. >> >>>> 2). Master is throwing the following exception: >>>> >>>> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >>>> (ProcessController-threads - 3) JBAS012017: Starting process >>>> 'Server:server-one' >>>> [Server:server-one] Error occurred during initialization of VM >>>> [Server:server-one] Server VM is only supported on ARMv7+ VFP >>> This ^^ seems to be the real error. Try removing ?-server? in the jvm-options. >> >> I removed -server from domain.sh, didn't realize its hardcoded in >> host.xml. It worked after commenting in host.xml. Is that a bug as >> well ? >> >> Arun >> >>> >>>> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >>>> (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' >>>> finished with an exit status of 1 >>>> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >>>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >>>> server server-one >>>> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >>>> (Controller Boot Thread) JBAS010922: Starting server server-two >>>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >>>> (ProcessController-threads - 3) JBAS012006: Failed to send data bytes >>>> to process 'Server:server-one' input stream: java.io.IOException: >>>> Stream closed >>>> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>> [rt.jar:1.7.0_40] >>>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>>> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>> [rt.jar:1.7.0_40] >>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>> [rt.jar:1.7.0_40] >>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>> [rt.jar:1.7.0_40] >>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>> [rt.jar:1.7.0_40] >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>> [rt.jar:1.7.0_40] >>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >>>> (ProcessController-threads - 3) JBAS016610: Failed to read a message: >>>> java.io.IOException: Stream closed >>>> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>> [rt.jar:1.7.0_40] >>>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>>> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>> [rt.jar:1.7.0_40] >>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>> [rt.jar:1.7.0_40] >>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>> [rt.jar:1.7.0_40] >>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>> [rt.jar:1.7.0_40] >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>> [rt.jar:1.7.0_40] >>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>> >>>> Same error for server-two as well. >>>> >>>> Trying to explicitly start server-three on slave gives the same error. >>>> >>>> This is all using 8.1 CR2. >>>> >>>> Any idea what might be wrong ? >>>> >>>> Thanks >>>> Aru >>>> >>>> -- >>>> http://blog.arungupta.me >>>> http://twitter.com/arungupta >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta From darran.lofthouse at jboss.com Wed May 28 05:06:19 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 28 May 2014 10:06:19 +0100 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> Message-ID: <5385A70B.2040206@jboss.com> I think it is a feature request as we know we never added support for http-remoting in domain mode ;-) An issue may already exist. On 28/05/14 00:13, Kabir Khan wrote: > > On 27 May 2014, at 23:39, Arun Gupta wrote: > >> Trying to following the instructions at: >> >> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >> >> This shows how to setup a 2-instance cluster in master/slave where >> master is on my laptop and slave is on a Raspi. Couple of questions >> ... >> >> 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ? >> >> >> >> >> >> FTR it only works with 9999, not with 9990. >> >> Domain Controller shows the message: >> >> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >> Controller Service Threads - 28) JBAS010918: Registered remote slave >> host "slave", WildFly 8.1.0.CR2 ?Kenny? > It looks like we hardcode the old ?remote://? protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the element take a ?protocol? attribute? >> >> >> 2). Master is throwing the following exception: >> >> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >> (ProcessController-threads - 3) JBAS012017: Starting process >> 'Server:server-one' >> [Server:server-one] Error occurred during initialization of VM >> [Server:server-one] Server VM is only supported on ARMv7+ VFP > This ^^ seems to be the real error. Try removing ?-server? in the jvm-options. > >> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >> (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' >> finished with an exit status of 1 >> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >> server server-one >> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >> (Controller Boot Thread) JBAS010922: Starting server server-two >> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >> (ProcessController-threads - 3) JBAS012006: Failed to send data bytes >> to process 'Server:server-one' input stream: java.io.IOException: >> Stream closed >> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >> [rt.jar:1.7.0_40] >> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >> [rt.jar:1.7.0_40] >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >> [rt.jar:1.7.0_40] >> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >> [rt.jar:1.7.0_40] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_40] >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_40] >> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >> (ProcessController-threads - 3) JBAS016610: Failed to read a message: >> java.io.IOException: Stream closed >> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >> [rt.jar:1.7.0_40] >> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >> [rt.jar:1.7.0_40] >> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >> [rt.jar:1.7.0_40] >> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >> [rt.jar:1.7.0_40] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_40] >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_40] >> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >> >> Same error for server-two as well. >> >> Trying to explicitly start server-three on slave gives the same error. >> >> This is all using 8.1 CR2. >> >> Any idea what might be wrong ? >> >> Thanks >> Aru >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From rachmato at redhat.com Wed May 28 09:00:21 2014 From: rachmato at redhat.com (Richard Achmatowicz) Date: Wed, 28 May 2014 09:00:21 -0400 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> Message-ID: <5385DDE5.90704@redhat.com> Arun The usual suspect in such a problem (updates to sessions not getting replicated between nodes) is JGroups not being able to send replication messages from one host to another. For example, if you are using the default udp stack of JGroups, you need to ensure that multicast communication is set up correctly on the machines you are using. On Linux boxes, the default firewall settings usually block multicast the JGroups messages from arriving successfully. If you are working on Linux, you can disable the firewall with: # iptables -F This will remove all firewall rules until the next reboot and allow the JGroups multicast messages to get through. Give that a shot. Configuring the JGroups transport is about the only additional configuration that is required for clustering to work. Richard On 28/05/14 04:39 AM, Kabir Khan wrote: > On 28 May 2014, at 03:49, Arun Gupta wrote: > >> I think master/slave is now configured on two nodes, Domain Controller >> shows the following message: >> >> [Host Controller] 16:34:18,888 INFO [org.jboss.as.domain] (Host >> Controller Service Threads - 32) JBAS010918: Registered remote slave >> host "slave", WildFly 8.1.0.CR2 "Kenny" >> >> Deployed/enabled a simple app and assigned to other-server-group and >> saw the log message: >> >> [Host Controller] 18:57:19,508 INFO [org.jboss.as.repository] (XNIO-1 >> task-9) JBAS014900: Content added at location >> /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content >> >> The app is now accessible on master and slave on :8330. >> >> By default, if an app is deployed to other-server-group on Domain >> Controller, does it get deployed to all servers in that server-group ? > Yes, and if you bring up more hosts with servers in that server group, or more servers in that group on an existing host, the app gets deployed to those as well. >> If the two nodes are on the same host then session replication work. >> This is the first time I've configured nodes on two different hosts >> and can't get session replication to work. That is, session attributes >> added to the application on one node (master) are not visible on the >> other node (slave). What configuration am I missing ? > I?m not so familiar with clustering so I am not sure. Richard? >> Arun >> >> On Tue, May 27, 2014 at 5:02 PM, Arun Gupta wrote: >>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan wrote: >>>> On 27 May 2014, at 23:39, Arun Gupta wrote: >>>> >>>>> Trying to following the instructions at: >>>>> >>>>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >>>>> >>>>> This shows how to setup a 2-instance cluster in master/slave where >>>>> master is on my laptop and slave is on a Raspi. Couple of questions >>>>> ... >>>>> >>>>> 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> FTR it only works with 9999, not with 9990. >>>>> >>>>> Domain Controller shows the message: >>>>> >>>>> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >>>>> Controller Service Threads - 28) JBAS010918: Registered remote slave >>>>> host "slave", WildFly 8.1.0.CR2 ?Kenny? >>>> It looks like we hardcode the old ?remote://? protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the element take a ?protocol? attribute? >>>>> >>> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. >>> >>>>> 2). Master is throwing the following exception: >>>>> >>>>> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >>>>> (ProcessController-threads - 3) JBAS012017: Starting process >>>>> 'Server:server-one' >>>>> [Server:server-one] Error occurred during initialization of VM >>>>> [Server:server-one] Server VM is only supported on ARMv7+ VFP >>>> This ^^ seems to be the real error. Try removing ?-server? in the jvm-options. >>> I removed -server from domain.sh, didn't realize its hardcoded in >>> host.xml. It worked after commenting in host.xml. Is that a bug as >>> well ? >>> >>> Arun >>> >>>>> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >>>>> (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' >>>>> finished with an exit status of 1 >>>>> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >>>>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >>>>> server server-one >>>>> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >>>>> (Controller Boot Thread) JBAS010922: Starting server server-two >>>>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >>>>> (ProcessController-threads - 3) JBAS012006: Failed to send data bytes >>>>> to process 'Server:server-one' input stream: java.io.IOException: >>>>> Stream closed >>>>> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>> [rt.jar:1.7.0_40] >>>>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>>>> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>> [rt.jar:1.7.0_40] >>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>> [rt.jar:1.7.0_40] >>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>> [rt.jar:1.7.0_40] >>>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>> [rt.jar:1.7.0_40] >>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>> [rt.jar:1.7.0_40] >>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >>>>> (ProcessController-threads - 3) JBAS016610: Failed to read a message: >>>>> java.io.IOException: Stream closed >>>>> at java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>> [rt.jar:1.7.0_40] >>>>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>>>> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>> [rt.jar:1.7.0_40] >>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>> [rt.jar:1.7.0_40] >>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>> [rt.jar:1.7.0_40] >>>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>> [rt.jar:1.7.0_40] >>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>> [rt.jar:1.7.0_40] >>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>> >>>>> Same error for server-two as well. >>>>> >>>>> Trying to explicitly start server-three on slave gives the same error. >>>>> >>>>> This is all using 8.1 CR2. >>>>> >>>>> Any idea what might be wrong ? >>>>> >>>>> Thanks >>>>> Aru >>>>> >>>>> -- >>>>> http://blog.arungupta.me >>>>> http://twitter.com/arungupta >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> -- >>> http://blog.arungupta.me >>> http://twitter.com/arungupta >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta From arun.gupta at gmail.com Wed May 28 09:11:49 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 28 May 2014 06:11:49 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <5385DDE5.90704@redhat.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> Message-ID: Richard, Is this a command or this entry needs to be commented in a file somewhere ? Does it matter if the master is on Mac and slave is on Raspbian ? Arun On Wed, May 28, 2014 at 6:00 AM, Richard Achmatowicz wrote: > Arun > > The usual suspect in such a problem (updates to sessions not getting > replicated between nodes) is JGroups not being able to send replication > messages from one host to another. For example, if you are using the default > udp stack of JGroups, you need to ensure that multicast communication is set > up correctly on the machines you are using. On Linux boxes, the default > firewall settings usually block multicast the JGroups messages from arriving > successfully. If you are working on Linux, you can disable the firewall > with: > > # iptables -F > > This will remove all firewall rules until the next reboot and allow the > JGroups multicast messages to get through. Give that a shot. Configuring the > JGroups transport is about the only additional configuration that is > required for clustering to work. > > Richard > > > On 28/05/14 04:39 AM, Kabir Khan wrote: >> >> On 28 May 2014, at 03:49, Arun Gupta wrote: >> >>> I think master/slave is now configured on two nodes, Domain Controller >>> shows the following message: >>> >>> [Host Controller] 16:34:18,888 INFO [org.jboss.as.domain] (Host >>> Controller Service Threads - 32) JBAS010918: Registered remote slave >>> host "slave", WildFly 8.1.0.CR2 "Kenny" >>> >>> Deployed/enabled a simple app and assigned to other-server-group and >>> saw the log message: >>> >>> [Host Controller] 18:57:19,508 INFO [org.jboss.as.repository] (XNIO-1 >>> task-9) JBAS014900: Content added at location >>> >>> /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content >>> >>> The app is now accessible on master and slave on :8330. >>> >>> By default, if an app is deployed to other-server-group on Domain >>> Controller, does it get deployed to all servers in that server-group ? >> >> Yes, and if you bring up more hosts with servers in that server group, or >> more servers in that group on an existing host, the app gets deployed to >> those as well. >>> >>> If the two nodes are on the same host then session replication work. >>> This is the first time I've configured nodes on two different hosts >>> and can't get session replication to work. That is, session attributes >>> added to the application on one node (master) are not visible on the >>> other node (slave). What configuration am I missing ? >> >> I?m not so familiar with clustering so I am not sure. Richard? >>> >>> Arun >>> >>> On Tue, May 27, 2014 at 5:02 PM, Arun Gupta wrote: >>>> >>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan >>>> wrote: >>>>> >>>>> On 27 May 2014, at 23:39, Arun Gupta wrote: >>>>> >>>>>> Trying to following the instructions at: >>>>>> >>>>>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >>>>>> >>>>>> This shows how to setup a 2-instance cluster in master/slave where >>>>>> master is on my laptop and slave is on a Raspi. Couple of questions >>>>>> ... >>>>>> >>>>>> 1). Why the following entry is still referring to 9999 ? Shouldn't it >>>>>> be 9990 ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> FTR it only works with 9999, not with 9990. >>>>>> >>>>>> Domain Controller shows the message: >>>>>> >>>>>> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >>>>>> Controller Service Threads - 28) JBAS010918: Registered remote slave >>>>>> host "slave", WildFly 8.1.0.CR2 ?Kenny? >>>>> >>>>> It looks like we hardcode the old ?remote://? protocol in >>>>> RemoteDomainConnectionService rather than the new http-remoting protocol, so >>>>> it is a bug. I am not sure if that is something we should attempt to >>>>> negotiate explicitly, or to make the element take a ?protocol? >>>>> attribute? >>>>>> >>>>>> >>>> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. >>>> >>>>>> 2). Master is throwing the following exception: >>>>>> >>>>>> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >>>>>> (ProcessController-threads - 3) JBAS012017: Starting process >>>>>> 'Server:server-one' >>>>>> [Server:server-one] Error occurred during initialization of VM >>>>>> [Server:server-one] Server VM is only supported on ARMv7+ VFP >>>>> >>>>> This ^^ seems to be the real error. Try removing ?-server? in the >>>>> jvm-options. >>>> >>>> I removed -server from domain.sh, didn't realize its hardcoded in >>>> host.xml. It worked after commenting in host.xml. Is that a bug as >>>> well ? >>>> >>>> Arun >>>> >>>>>> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >>>>>> (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' >>>>>> finished with an exit status of 1 >>>>>> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >>>>>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >>>>>> server server-one >>>>>> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >>>>>> (Controller Boot Thread) JBAS010922: Starting server server-two >>>>>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >>>>>> (ProcessController-threads - 3) JBAS012006: Failed to send data bytes >>>>>> to process 'Server:server-one' input stream: java.io.IOException: >>>>>> Stream closed >>>>>> at >>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>> [rt.jar:1.7.0_40] >>>>>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>>>>> at >>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>> [rt.jar:1.7.0_40] >>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>> [rt.jar:1.7.0_40] >>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>> [rt.jar:1.7.0_40] >>>>>> at >>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>> [rt.jar:1.7.0_40] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>> [rt.jar:1.7.0_40] >>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >>>>>> (ProcessController-threads - 3) JBAS016610: Failed to read a message: >>>>>> java.io.IOException: Stream closed >>>>>> at >>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>> [rt.jar:1.7.0_40] >>>>>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>>>>> at >>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>> [rt.jar:1.7.0_40] >>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>> [rt.jar:1.7.0_40] >>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>> [rt.jar:1.7.0_40] >>>>>> at >>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>> [rt.jar:1.7.0_40] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>> [rt.jar:1.7.0_40] >>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>> >>>>>> Same error for server-two as well. >>>>>> >>>>>> Trying to explicitly start server-three on slave gives the same error. >>>>>> >>>>>> This is all using 8.1 CR2. >>>>>> >>>>>> Any idea what might be wrong ? >>>>>> >>>>>> Thanks >>>>>> Aru >>>>>> >>>>>> -- >>>>>> http://blog.arungupta.me >>>>>> http://twitter.com/arungupta >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> >>>> -- >>>> http://blog.arungupta.me >>>> http://twitter.com/arungupta >>> >>> >>> >>> -- >>> http://blog.arungupta.me >>> http://twitter.com/arungupta > > -- http://blog.arungupta.me http://twitter.com/arungupta From rachmato at redhat.com Wed May 28 09:29:57 2014 From: rachmato at redhat.com (Richard Achmatowicz) Date: Wed, 28 May 2014 09:29:57 -0400 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> Message-ID: <5385E4D5.9080803@redhat.com> Hi Arun It's a Linux command and applies to a Linux OS only. You need to do it via root in order to use it. Disabling firewalls and configuring multicast communication is unfortunately OS dependent. I'm not a Mac user, but from a quick Google, it looks as through it is disabled/enabled from System Preferences. If Raspbian is based on Debian, then the iptables command may be similarly available from root. If none of this works, then there is the option of further debugging with some JGroups tools, or simply configuring JGroups to use a TCP-based stack. By the way, when you have started two nodes which you are expecting to connect, you should see group membership messages appearing in the console logs, near the end of the startup. You should see both hosts (IP addresses) listed in the group membership - that will confirm that JGroups communication is working correctly. If you only see one IP address on each machine, the messages are not getting through. Richard On 28/05/14 09:11 AM, Arun Gupta wrote: > Richard, > > Is this a command or this entry needs to be commented in a file somewhere ? > > Does it matter if the master is on Mac and slave is on Raspbian ? > > Arun > > On Wed, May 28, 2014 at 6:00 AM, Richard Achmatowicz > wrote: >> Arun >> >> The usual suspect in such a problem (updates to sessions not getting >> replicated between nodes) is JGroups not being able to send replication >> messages from one host to another. For example, if you are using the default >> udp stack of JGroups, you need to ensure that multicast communication is set >> up correctly on the machines you are using. On Linux boxes, the default >> firewall settings usually block multicast the JGroups messages from arriving >> successfully. If you are working on Linux, you can disable the firewall >> with: >> >> # iptables -F >> >> This will remove all firewall rules until the next reboot and allow the >> JGroups multicast messages to get through. Give that a shot. Configuring the >> JGroups transport is about the only additional configuration that is >> required for clustering to work. >> >> Richard >> >> >> On 28/05/14 04:39 AM, Kabir Khan wrote: >>> On 28 May 2014, at 03:49, Arun Gupta wrote: >>> >>>> I think master/slave is now configured on two nodes, Domain Controller >>>> shows the following message: >>>> >>>> [Host Controller] 16:34:18,888 INFO [org.jboss.as.domain] (Host >>>> Controller Service Threads - 32) JBAS010918: Registered remote slave >>>> host "slave", WildFly 8.1.0.CR2 "Kenny" >>>> >>>> Deployed/enabled a simple app and assigned to other-server-group and >>>> saw the log message: >>>> >>>> [Host Controller] 18:57:19,508 INFO [org.jboss.as.repository] (XNIO-1 >>>> task-9) JBAS014900: Content added at location >>>> >>>> /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content >>>> >>>> The app is now accessible on master and slave on :8330. >>>> >>>> By default, if an app is deployed to other-server-group on Domain >>>> Controller, does it get deployed to all servers in that server-group ? >>> Yes, and if you bring up more hosts with servers in that server group, or >>> more servers in that group on an existing host, the app gets deployed to >>> those as well. >>>> If the two nodes are on the same host then session replication work. >>>> This is the first time I've configured nodes on two different hosts >>>> and can't get session replication to work. That is, session attributes >>>> added to the application on one node (master) are not visible on the >>>> other node (slave). What configuration am I missing ? >>> I?m not so familiar with clustering so I am not sure. Richard? >>>> Arun >>>> >>>> On Tue, May 27, 2014 at 5:02 PM, Arun Gupta wrote: >>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan >>>>> wrote: >>>>>> On 27 May 2014, at 23:39, Arun Gupta wrote: >>>>>> >>>>>>> Trying to following the instructions at: >>>>>>> >>>>>>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >>>>>>> >>>>>>> This shows how to setup a 2-instance cluster in master/slave where >>>>>>> master is on my laptop and slave is on a Raspi. Couple of questions >>>>>>> ... >>>>>>> >>>>>>> 1). Why the following entry is still referring to 9999 ? Shouldn't it >>>>>>> be 9990 ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> FTR it only works with 9999, not with 9990. >>>>>>> >>>>>>> Domain Controller shows the message: >>>>>>> >>>>>>> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >>>>>>> Controller Service Threads - 28) JBAS010918: Registered remote slave >>>>>>> host "slave", WildFly 8.1.0.CR2 ?Kenny? >>>>>> It looks like we hardcode the old ?remote://? protocol in >>>>>> RemoteDomainConnectionService rather than the new http-remoting protocol, so >>>>>> it is a bug. I am not sure if that is something we should attempt to >>>>>> negotiate explicitly, or to make the element take a ?protocol? >>>>>> attribute? >>>>>>> >>>>> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. >>>>> >>>>>>> 2). Master is throwing the following exception: >>>>>>> >>>>>>> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >>>>>>> (ProcessController-threads - 3) JBAS012017: Starting process >>>>>>> 'Server:server-one' >>>>>>> [Server:server-one] Error occurred during initialization of VM >>>>>>> [Server:server-one] Server VM is only supported on ARMv7+ VFP >>>>>> This ^^ seems to be the real error. Try removing ?-server? in the >>>>>> jvm-options. >>>>> I removed -server from domain.sh, didn't realize its hardcoded in >>>>> host.xml. It worked after commenting in host.xml. Is that a bug as >>>>> well ? >>>>> >>>>> Arun >>>>> >>>>>>> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >>>>>>> (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' >>>>>>> finished with an exit status of 1 >>>>>>> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >>>>>>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >>>>>>> server server-one >>>>>>> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >>>>>>> (Controller Boot Thread) JBAS010922: Starting server server-two >>>>>>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >>>>>>> (ProcessController-threads - 3) JBAS012006: Failed to send data bytes >>>>>>> to process 'Server:server-one' input stream: java.io.IOException: >>>>>>> Stream closed >>>>>>> at >>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>>>>>> at >>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >>>>>>> (ProcessController-threads - 3) JBAS016610: Failed to read a message: >>>>>>> java.io.IOException: Stream closed >>>>>>> at >>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at java.io.OutputStream.write(OutputStream.java:116) [rt.jar:1.7.0_40] >>>>>>> at >>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>> [rt.jar:1.7.0_40] >>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>>> >>>>>>> Same error for server-two as well. >>>>>>> >>>>>>> Trying to explicitly start server-three on slave gives the same error. >>>>>>> >>>>>>> This is all using 8.1 CR2. >>>>>>> >>>>>>> Any idea what might be wrong ? >>>>>>> >>>>>>> Thanks >>>>>>> Aru >>>>>>> >>>>>>> -- >>>>>>> http://blog.arungupta.me >>>>>>> http://twitter.com/arungupta >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>>> -- >>>>> http://blog.arungupta.me >>>>> http://twitter.com/arungupta >>>> >>>> >>>> -- >>>> http://blog.arungupta.me >>>> http://twitter.com/arungupta >> > > From ehugonne at redhat.com Wed May 28 10:30:20 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Wed, 28 May 2014 16:30:20 +0200 Subject: [wildfly-dev] Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism Message-ID: <5385F2FC.8050109@redhat.com> Hi, Yesterday there was a presentation of the Java8 Stream API at the local JUG. According to the speaker (Paul Sandoz) parallelism should be disabled in webapps because : "...a machine serving web requests is usually sized/configured to maximize throughput. If web application code was using parallel streams then CPU resources would be consumed computing results that could otherwise be used to serve other web requests. A stream computation running on a fork/join pool will not block, it will try and go as fast as possible using as many resources as possible." What do you think ? Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140528/22b63c0e/attachment.bin From jason.greene at redhat.com Wed May 28 11:26:36 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 28 May 2014 10:26:36 -0500 Subject: [wildfly-dev] Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism In-Reply-To: <5385F2FC.8050109@redhat.com> References: <5385F2FC.8050109@redhat.com> Message-ID: <7B1B881C-8698-4F34-BCDB-54087085220D@redhat.com> My complaint with the parallel API is that it makes it too easy. Just 16 characters are required to do some operation concurrently without thinking about the resource usage impact and whether or not the task at hand is even beneficial in parallel. So my fear is it will be over-used and create problems. His point is basically right that a typical web architecture is structured to support many simultaneous users, and you therefore need to minimize the resource consumption of each action in the application. However, there are use-cases where it would make sense, such as cooperative computational applications. I think the big problem for us will be if frameworks we consume start making haphazard use of the platform FJ pool, so once we move to 8 we likely need to audit this area. On May 28, 2014, at 9:30 AM, Emmanuel Hugonnet wrote: > Hi, > Yesterday there was a presentation of the Java8 Stream API at the local JUG. > According to the speaker (Paul Sandoz) parallelism should be disabled in webapps because : > "...a machine serving web requests is usually sized/configured to maximize throughput. If web application code was using parallel streams > then CPU resources would be consumed computing results that could otherwise be used to serve other web requests. A stream computation > running on a fork/join pool will not block, it will try and go as fast as possible using as many resources as possible." > > What do you think ? > Emmanuel > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jonathan.halliday at redhat.com Wed May 28 12:40:40 2014 From: jonathan.halliday at redhat.com (Jonathan Halliday) Date: Wed, 28 May 2014 17:40:40 +0100 Subject: [wildfly-dev] Disabling parallelism by tweaking java.util.concurrent.ForkJoinPool.common.parallelism In-Reply-To: <5385F2FC.8050109@redhat.com> References: <5385F2FC.8050109@redhat.com> Message-ID: <53861188.6050603@redhat.com> Whilst disabling parallelism may be a reasonable default to stop less experienced users shooting themselves in the foot, I think it's a big (and ill advised) jump to go from 'using multiple CPUs for intensive per-request computation in the web tier is bad' to 'parallelism should be disabled'. The former advice is already borderline, as achieving latencies short enough to satisfy users can require utilising more than one core. 'maximise throughput' is a misguided appeal to the batch oriented model which can amortise fixed costs. There is no material benefit to that as web requests rarely share a useful amount of common work. Web tier throughput may actually be better if a single request is completed more quickly as a result of using multiple cores, since it will benefit from hot caches and release RAM faster, allowing more efficient GC. More generally, dispatching multiple remote requests in parallel can benefit from multiple threads without using excessive CPU use. In the web tier something that looks like an in-memory Collection can often be a lazy-load proxy over a db result set, remote K/V cache or such. In such cases pooled fork/join threads may block, not to mention endless hours of debugging fun with non-'thread safe' (sic) implementations like Hibernate's Session. On the one hand you want to dispatch independent remote requests in parallel as much as you can, whilst on the other you have to pay attention to the support or lack of it that is provided for that in the libraries you're using. For the foreseeable future we will be living in a world where some APIs have been retrofitted for parallel/async behaviour (e.g. servlets, collections) and some have not (e.g. JDBC/JPA). Best practice for gluing the two models together is not as simple as 'parallelism should be disabled'. It's important to carefully contextualise and guidelines and back them with empirical evidence. Do you have a link the presentation deck? I'm curious to see what use case(s) he benchmarked to reach his conclusions. Jonathan. On 05/28/2014 03:30 PM, Emmanuel Hugonnet wrote: > Hi, > Yesterday there was a presentation of the Java8 Stream API at the local JUG. > According to the speaker (Paul Sandoz) parallelism should be disabled in webapps because : > "...a machine serving web requests is usually sized/configured to maximize throughput. If web application code was using parallel streams > then CPU resources would be consumed computing results that could otherwise be used to serve other web requests. A stream computation > running on a fork/join pool will not block, it will try and go as fast as possible using as many resources as possible." > > What do you think ? > Emmanuel > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill(Ireland) From arun.gupta at gmail.com Wed May 28 16:08:42 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 28 May 2014 13:08:42 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <5385E4D5.9080803@redhat.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> Message-ID: "iptables --flush" did the trick on Raspbian. Now I have Domain Controller running on one Raspi, and Host Controller running on another. However the slave is throwing the following exception: [Server:server-three] 19:56:54,746 ERROR [org.hornetq.core.server] (Thread-1 (HornetQ-client-netty-threads-6928453)) HQ224058: Stopping ClusterManager. As it failed to authenticate with the cluster: HQ119099: Unable to authenticate cluster user: HORNETQ.CLUSTER.ADMIN.USER [Server:server-three] 19:56:54,982 INFO [org.hornetq.core.server] (Thread-6 (HornetQ-server-HornetQServerImpl::serverUUID=2b53cedf-e6a2-11e3-9d57-71d44db5d6ff-27664265)) HQ221029: stopped bridge sf.my-cluster.5e79c85f-e69d-11e3-a06c-37b4b1e261b8 [Server:server-three] 19:56:55,833 ERROR [org.hornetq.core.server] (default I/O-1) HQ224018: Failed to create session: HornetQClusterSecurityException[errorType=CLUSTER_SECURITY_EXCEPTION message=HQ119099: Unable to authenticate cluster user: HORNETQ.CLUSTER.ADMIN.USER] [Server:server-three] at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:124) [Server:server-three] at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:1014) [Server:server-three] at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150) I gather the following value in domain.xml needs to be changed: ${jboss.messaging.cluster.password:CHANGE ME!!} But to what ? I've created a password for master and slave only so far. How is cluster password different from them ? Arun On Wed, May 28, 2014 at 6:29 AM, Richard Achmatowicz wrote: > Hi Arun > > It's a Linux command and applies to a Linux OS only. You need to do it via > root in order to use it. > Disabling firewalls and configuring multicast communication is unfortunately > OS dependent. > I'm not a Mac user, but from a quick Google, it looks as through it is > disabled/enabled from System Preferences. > If Raspbian is based on Debian, then the iptables command may be similarly > available from root. > > If none of this works, then there is the option of further debugging with > some JGroups tools, or simply configuring JGroups to use a TCP-based stack. > > By the way, when you have started two nodes which you are expecting to > connect, you should see group membership messages appearing in the console > logs, near the end of the startup. You should see both hosts (IP addresses) > listed in the group membership - that will confirm that JGroups > communication is working correctly. If you only see one IP address on each > machine, the messages are not getting through. > > > Richard > > > On 28/05/14 09:11 AM, Arun Gupta wrote: >> >> Richard, >> >> Is this a command or this entry needs to be commented in a file somewhere >> ? >> >> Does it matter if the master is on Mac and slave is on Raspbian ? >> >> Arun >> >> On Wed, May 28, 2014 at 6:00 AM, Richard Achmatowicz >> wrote: >>> >>> Arun >>> >>> The usual suspect in such a problem (updates to sessions not getting >>> replicated between nodes) is JGroups not being able to send replication >>> messages from one host to another. For example, if you are using the >>> default >>> udp stack of JGroups, you need to ensure that multicast communication is >>> set >>> up correctly on the machines you are using. On Linux boxes, the default >>> firewall settings usually block multicast the JGroups messages from >>> arriving >>> successfully. If you are working on Linux, you can disable the firewall >>> with: >>> >>> # iptables -F >>> >>> This will remove all firewall rules until the next reboot and allow the >>> JGroups multicast messages to get through. Give that a shot. Configuring >>> the >>> JGroups transport is about the only additional configuration that is >>> required for clustering to work. >>> >>> Richard >>> >>> >>> On 28/05/14 04:39 AM, Kabir Khan wrote: >>>> >>>> On 28 May 2014, at 03:49, Arun Gupta wrote: >>>> >>>>> I think master/slave is now configured on two nodes, Domain Controller >>>>> shows the following message: >>>>> >>>>> [Host Controller] 16:34:18,888 INFO [org.jboss.as.domain] (Host >>>>> Controller Service Threads - 32) JBAS010918: Registered remote slave >>>>> host "slave", WildFly 8.1.0.CR2 "Kenny" >>>>> >>>>> Deployed/enabled a simple app and assigned to other-server-group and >>>>> saw the log message: >>>>> >>>>> [Host Controller] 18:57:19,508 INFO [org.jboss.as.repository] (XNIO-1 >>>>> task-9) JBAS014900: Content added at location >>>>> >>>>> >>>>> /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content >>>>> >>>>> The app is now accessible on master and slave on :8330. >>>>> >>>>> By default, if an app is deployed to other-server-group on Domain >>>>> Controller, does it get deployed to all servers in that server-group ? >>>> >>>> Yes, and if you bring up more hosts with servers in that server group, >>>> or >>>> more servers in that group on an existing host, the app gets deployed to >>>> those as well. >>>>> >>>>> If the two nodes are on the same host then session replication work. >>>>> This is the first time I've configured nodes on two different hosts >>>>> and can't get session replication to work. That is, session attributes >>>>> added to the application on one node (master) are not visible on the >>>>> other node (slave). What configuration am I missing ? >>>> >>>> I?m not so familiar with clustering so I am not sure. Richard? >>>>> >>>>> Arun >>>>> >>>>> On Tue, May 27, 2014 at 5:02 PM, Arun Gupta >>>>> wrote: >>>>>> >>>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan >>>>>> wrote: >>>>>>> >>>>>>> On 27 May 2014, at 23:39, Arun Gupta wrote: >>>>>>> >>>>>>>> Trying to following the instructions at: >>>>>>>> >>>>>>>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >>>>>>>> >>>>>>>> This shows how to setup a 2-instance cluster in master/slave where >>>>>>>> master is on my laptop and slave is on a Raspi. Couple of questions >>>>>>>> ... >>>>>>>> >>>>>>>> 1). Why the following entry is still referring to 9999 ? Shouldn't >>>>>>>> it >>>>>>>> be 9990 ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> FTR it only works with 9999, not with 9990. >>>>>>>> >>>>>>>> Domain Controller shows the message: >>>>>>>> >>>>>>>> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >>>>>>>> Controller Service Threads - 28) JBAS010918: Registered remote slave >>>>>>>> host "slave", WildFly 8.1.0.CR2 ?Kenny? >>>>>>> >>>>>>> It looks like we hardcode the old ?remote://? protocol in >>>>>>> RemoteDomainConnectionService rather than the new http-remoting >>>>>>> protocol, so >>>>>>> it is a bug. I am not sure if that is something we should attempt to >>>>>>> negotiate explicitly, or to make the element take a >>>>>>> ?protocol? >>>>>>> attribute? >>>>>>>> >>>>>>>> >>>>>> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. >>>>>> >>>>>>>> 2). Master is throwing the following exception: >>>>>>>> >>>>>>>> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >>>>>>>> (ProcessController-threads - 3) JBAS012017: Starting process >>>>>>>> 'Server:server-one' >>>>>>>> [Server:server-one] Error occurred during initialization of VM >>>>>>>> [Server:server-one] Server VM is only supported on ARMv7+ VFP >>>>>>> >>>>>>> This ^^ seems to be the real error. Try removing ?-server? in the >>>>>>> jvm-options. >>>>>> >>>>>> I removed -server from domain.sh, didn't realize its hardcoded in >>>>>> host.xml. It worked after commenting in host.xml. Is that a bug as >>>>>> well ? >>>>>> >>>>>> Arun >>>>>> >>>>>>>> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >>>>>>>> (reaper for Server:server-one) JBAS012010: Process >>>>>>>> 'Server:server-one' >>>>>>>> finished with an exit status of 1 >>>>>>>> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >>>>>>>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >>>>>>>> server server-one >>>>>>>> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >>>>>>>> (Controller Boot Thread) JBAS010922: Starting server server-two >>>>>>>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >>>>>>>> (ProcessController-threads - 3) JBAS012006: Failed to send data >>>>>>>> bytes >>>>>>>> to process 'Server:server-one' input stream: java.io.IOException: >>>>>>>> Stream closed >>>>>>>> at >>>>>>>> >>>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.OutputStream.write(OutputStream.java:116) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>>>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >>>>>>>> (ProcessController-threads - 3) JBAS016610: Failed to read a >>>>>>>> message: >>>>>>>> java.io.IOException: Stream closed >>>>>>>> at >>>>>>>> >>>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.OutputStream.write(OutputStream.java:116) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>>>> >>>>>>>> Same error for server-two as well. >>>>>>>> >>>>>>>> Trying to explicitly start server-three on slave gives the same >>>>>>>> error. >>>>>>>> >>>>>>>> This is all using 8.1 CR2. >>>>>>>> >>>>>>>> Any idea what might be wrong ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Aru >>>>>>>> >>>>>>>> -- >>>>>>>> http://blog.arungupta.me >>>>>>>> http://twitter.com/arungupta >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://blog.arungupta.me >>>>>> http://twitter.com/arungupta >>>>> >>>>> >>>>> >>>>> -- >>>>> http://blog.arungupta.me >>>>> http://twitter.com/arungupta >>> >>> >> >> > -- http://blog.arungupta.me http://twitter.com/arungupta From arun.gupta at gmail.com Wed May 28 16:31:35 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 28 May 2014 13:31:35 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <5385E4D5.9080803@redhat.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> Message-ID: Richard, Now I can: - Configure Domain Controller (master) on one Raspi - Configure Host Controller (slave) on another Raspi - Deploy an application to the cluster using jboss-cli However the session replication does not seem to work, i.e. session attributes added to HTTP session on master are not replicated to slave, and vice versa. How do I get that piece working ? Arun On Wed, May 28, 2014 at 6:29 AM, Richard Achmatowicz wrote: > Hi Arun > > It's a Linux command and applies to a Linux OS only. You need to do it via > root in order to use it. > Disabling firewalls and configuring multicast communication is unfortunately > OS dependent. > I'm not a Mac user, but from a quick Google, it looks as through it is > disabled/enabled from System Preferences. > If Raspbian is based on Debian, then the iptables command may be similarly > available from root. > > If none of this works, then there is the option of further debugging with > some JGroups tools, or simply configuring JGroups to use a TCP-based stack. > > By the way, when you have started two nodes which you are expecting to > connect, you should see group membership messages appearing in the console > logs, near the end of the startup. You should see both hosts (IP addresses) > listed in the group membership - that will confirm that JGroups > communication is working correctly. If you only see one IP address on each > machine, the messages are not getting through. > > > Richard > > > On 28/05/14 09:11 AM, Arun Gupta wrote: >> >> Richard, >> >> Is this a command or this entry needs to be commented in a file somewhere >> ? >> >> Does it matter if the master is on Mac and slave is on Raspbian ? >> >> Arun >> >> On Wed, May 28, 2014 at 6:00 AM, Richard Achmatowicz >> wrote: >>> >>> Arun >>> >>> The usual suspect in such a problem (updates to sessions not getting >>> replicated between nodes) is JGroups not being able to send replication >>> messages from one host to another. For example, if you are using the >>> default >>> udp stack of JGroups, you need to ensure that multicast communication is >>> set >>> up correctly on the machines you are using. On Linux boxes, the default >>> firewall settings usually block multicast the JGroups messages from >>> arriving >>> successfully. If you are working on Linux, you can disable the firewall >>> with: >>> >>> # iptables -F >>> >>> This will remove all firewall rules until the next reboot and allow the >>> JGroups multicast messages to get through. Give that a shot. Configuring >>> the >>> JGroups transport is about the only additional configuration that is >>> required for clustering to work. >>> >>> Richard >>> >>> >>> On 28/05/14 04:39 AM, Kabir Khan wrote: >>>> >>>> On 28 May 2014, at 03:49, Arun Gupta wrote: >>>> >>>>> I think master/slave is now configured on two nodes, Domain Controller >>>>> shows the following message: >>>>> >>>>> [Host Controller] 16:34:18,888 INFO [org.jboss.as.domain] (Host >>>>> Controller Service Threads - 32) JBAS010918: Registered remote slave >>>>> host "slave", WildFly 8.1.0.CR2 "Kenny" >>>>> >>>>> Deployed/enabled a simple app and assigned to other-server-group and >>>>> saw the log message: >>>>> >>>>> [Host Controller] 18:57:19,508 INFO [org.jboss.as.repository] (XNIO-1 >>>>> task-9) JBAS014900: Content added at location >>>>> >>>>> >>>>> /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content >>>>> >>>>> The app is now accessible on master and slave on :8330. >>>>> >>>>> By default, if an app is deployed to other-server-group on Domain >>>>> Controller, does it get deployed to all servers in that server-group ? >>>> >>>> Yes, and if you bring up more hosts with servers in that server group, >>>> or >>>> more servers in that group on an existing host, the app gets deployed to >>>> those as well. >>>>> >>>>> If the two nodes are on the same host then session replication work. >>>>> This is the first time I've configured nodes on two different hosts >>>>> and can't get session replication to work. That is, session attributes >>>>> added to the application on one node (master) are not visible on the >>>>> other node (slave). What configuration am I missing ? >>>> >>>> I?m not so familiar with clustering so I am not sure. Richard? >>>>> >>>>> Arun >>>>> >>>>> On Tue, May 27, 2014 at 5:02 PM, Arun Gupta >>>>> wrote: >>>>>> >>>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan >>>>>> wrote: >>>>>>> >>>>>>> On 27 May 2014, at 23:39, Arun Gupta wrote: >>>>>>> >>>>>>>> Trying to following the instructions at: >>>>>>>> >>>>>>>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >>>>>>>> >>>>>>>> This shows how to setup a 2-instance cluster in master/slave where >>>>>>>> master is on my laptop and slave is on a Raspi. Couple of questions >>>>>>>> ... >>>>>>>> >>>>>>>> 1). Why the following entry is still referring to 9999 ? Shouldn't >>>>>>>> it >>>>>>>> be 9990 ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> FTR it only works with 9999, not with 9990. >>>>>>>> >>>>>>>> Domain Controller shows the message: >>>>>>>> >>>>>>>> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >>>>>>>> Controller Service Threads - 28) JBAS010918: Registered remote slave >>>>>>>> host "slave", WildFly 8.1.0.CR2 ?Kenny? >>>>>>> >>>>>>> It looks like we hardcode the old ?remote://? protocol in >>>>>>> RemoteDomainConnectionService rather than the new http-remoting >>>>>>> protocol, so >>>>>>> it is a bug. I am not sure if that is something we should attempt to >>>>>>> negotiate explicitly, or to make the element take a >>>>>>> ?protocol? >>>>>>> attribute? >>>>>>>> >>>>>>>> >>>>>> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. >>>>>> >>>>>>>> 2). Master is throwing the following exception: >>>>>>>> >>>>>>>> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >>>>>>>> (ProcessController-threads - 3) JBAS012017: Starting process >>>>>>>> 'Server:server-one' >>>>>>>> [Server:server-one] Error occurred during initialization of VM >>>>>>>> [Server:server-one] Server VM is only supported on ARMv7+ VFP >>>>>>> >>>>>>> This ^^ seems to be the real error. Try removing ?-server? in the >>>>>>> jvm-options. >>>>>> >>>>>> I removed -server from domain.sh, didn't realize its hardcoded in >>>>>> host.xml. It worked after commenting in host.xml. Is that a bug as >>>>>> well ? >>>>>> >>>>>> Arun >>>>>> >>>>>>>> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >>>>>>>> (reaper for Server:server-one) JBAS012010: Process >>>>>>>> 'Server:server-one' >>>>>>>> finished with an exit status of 1 >>>>>>>> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >>>>>>>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >>>>>>>> server server-one >>>>>>>> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >>>>>>>> (Controller Boot Thread) JBAS010922: Starting server server-two >>>>>>>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >>>>>>>> (ProcessController-threads - 3) JBAS012006: Failed to send data >>>>>>>> bytes >>>>>>>> to process 'Server:server-one' input stream: java.io.IOException: >>>>>>>> Stream closed >>>>>>>> at >>>>>>>> >>>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.OutputStream.write(OutputStream.java:116) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>>>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >>>>>>>> (ProcessController-threads - 3) JBAS016610: Failed to read a >>>>>>>> message: >>>>>>>> java.io.IOException: Stream closed >>>>>>>> at >>>>>>>> >>>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.OutputStream.write(OutputStream.java:116) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>> at >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at >>>>>>>> >>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>>> [rt.jar:1.7.0_40] >>>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>>>> >>>>>>>> Same error for server-two as well. >>>>>>>> >>>>>>>> Trying to explicitly start server-three on slave gives the same >>>>>>>> error. >>>>>>>> >>>>>>>> This is all using 8.1 CR2. >>>>>>>> >>>>>>>> Any idea what might be wrong ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Aru >>>>>>>> >>>>>>>> -- >>>>>>>> http://blog.arungupta.me >>>>>>>> http://twitter.com/arungupta >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://blog.arungupta.me >>>>>> http://twitter.com/arungupta >>>>> >>>>> >>>>> >>>>> -- >>>>> http://blog.arungupta.me >>>>> http://twitter.com/arungupta >>> >>> >> >> > -- http://blog.arungupta.me http://twitter.com/arungupta From jason.greene at redhat.com Wed May 28 17:01:10 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 28 May 2014 16:01:10 -0500 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> Message-ID: On May 28, 2014, at 3:31 PM, Arun Gupta wrote: > Richard, > > Now I can: > > - Configure Domain Controller (master) on one Raspi > - Configure Host Controller (slave) on another Raspi > - Deploy an application to the cluster using jboss-cli Just in case this is a misconception, clustering and domain management are independent things. You don?t need one to do the other. For example see standalone-full-ha.xml. > > However the session replication does not seem to work, i.e. session > attributes added to HTTP session on master are not replicated to > slave, and vice versa. How do I get that piece working ? Do you have distributable in your web.xml, and does the profile your server is using have session replication configured (e.g using the ha profile or the ha-full profile)? > Arun > > > On Wed, May 28, 2014 at 6:29 AM, Richard Achmatowicz > wrote: >> Hi Arun >> >> It's a Linux command and applies to a Linux OS only. You need to do it via >> root in order to use it. >> Disabling firewalls and configuring multicast communication is unfortunately >> OS dependent. >> I'm not a Mac user, but from a quick Google, it looks as through it is >> disabled/enabled from System Preferences. >> If Raspbian is based on Debian, then the iptables command may be similarly >> available from root. >> >> If none of this works, then there is the option of further debugging with >> some JGroups tools, or simply configuring JGroups to use a TCP-based stack. >> >> By the way, when you have started two nodes which you are expecting to >> connect, you should see group membership messages appearing in the console >> logs, near the end of the startup. You should see both hosts (IP addresses) >> listed in the group membership - that will confirm that JGroups >> communication is working correctly. If you only see one IP address on each >> machine, the messages are not getting through. >> >> >> Richard >> >> >> On 28/05/14 09:11 AM, Arun Gupta wrote: >>> >>> Richard, >>> >>> Is this a command or this entry needs to be commented in a file somewhere >>> ? >>> >>> Does it matter if the master is on Mac and slave is on Raspbian ? >>> >>> Arun >>> >>> On Wed, May 28, 2014 at 6:00 AM, Richard Achmatowicz >>> wrote: >>>> >>>> Arun >>>> >>>> The usual suspect in such a problem (updates to sessions not getting >>>> replicated between nodes) is JGroups not being able to send replication >>>> messages from one host to another. For example, if you are using the >>>> default >>>> udp stack of JGroups, you need to ensure that multicast communication is >>>> set >>>> up correctly on the machines you are using. On Linux boxes, the default >>>> firewall settings usually block multicast the JGroups messages from >>>> arriving >>>> successfully. If you are working on Linux, you can disable the firewall >>>> with: >>>> >>>> # iptables -F >>>> >>>> This will remove all firewall rules until the next reboot and allow the >>>> JGroups multicast messages to get through. Give that a shot. Configuring >>>> the >>>> JGroups transport is about the only additional configuration that is >>>> required for clustering to work. >>>> >>>> Richard >>>> >>>> >>>> On 28/05/14 04:39 AM, Kabir Khan wrote: >>>>> >>>>> On 28 May 2014, at 03:49, Arun Gupta wrote: >>>>> >>>>>> I think master/slave is now configured on two nodes, Domain Controller >>>>>> shows the following message: >>>>>> >>>>>> [Host Controller] 16:34:18,888 INFO [org.jboss.as.domain] (Host >>>>>> Controller Service Threads - 32) JBAS010918: Registered remote slave >>>>>> host "slave", WildFly 8.1.0.CR2 "Kenny" >>>>>> >>>>>> Deployed/enabled a simple app and assigned to other-server-group and >>>>>> saw the log message: >>>>>> >>>>>> [Host Controller] 18:57:19,508 INFO [org.jboss.as.repository] (XNIO-1 >>>>>> task-9) JBAS014900: Content added at location >>>>>> >>>>>> >>>>>> /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content >>>>>> >>>>>> The app is now accessible on master and slave on :8330. >>>>>> >>>>>> By default, if an app is deployed to other-server-group on Domain >>>>>> Controller, does it get deployed to all servers in that server-group ? >>>>> >>>>> Yes, and if you bring up more hosts with servers in that server group, >>>>> or >>>>> more servers in that group on an existing host, the app gets deployed to >>>>> those as well. >>>>>> >>>>>> If the two nodes are on the same host then session replication work. >>>>>> This is the first time I've configured nodes on two different hosts >>>>>> and can't get session replication to work. That is, session attributes >>>>>> added to the application on one node (master) are not visible on the >>>>>> other node (slave). What configuration am I missing ? >>>>> >>>>> I?m not so familiar with clustering so I am not sure. Richard? >>>>>> >>>>>> Arun >>>>>> >>>>>> On Tue, May 27, 2014 at 5:02 PM, Arun Gupta >>>>>> wrote: >>>>>>> >>>>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan >>>>>>> wrote: >>>>>>>> >>>>>>>> On 27 May 2014, at 23:39, Arun Gupta wrote: >>>>>>>> >>>>>>>>> Trying to following the instructions at: >>>>>>>>> >>>>>>>>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto >>>>>>>>> >>>>>>>>> This shows how to setup a 2-instance cluster in master/slave where >>>>>>>>> master is on my laptop and slave is on a Raspi. Couple of questions >>>>>>>>> ... >>>>>>>>> >>>>>>>>> 1). Why the following entry is still referring to 9999 ? Shouldn't >>>>>>>>> it >>>>>>>>> be 9990 ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> FTR it only works with 9999, not with 9990. >>>>>>>>> >>>>>>>>> Domain Controller shows the message: >>>>>>>>> >>>>>>>>> [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host >>>>>>>>> Controller Service Threads - 28) JBAS010918: Registered remote slave >>>>>>>>> host "slave", WildFly 8.1.0.CR2 ?Kenny? >>>>>>>> >>>>>>>> It looks like we hardcode the old ?remote://? protocol in >>>>>>>> RemoteDomainConnectionService rather than the new http-remoting >>>>>>>> protocol, so >>>>>>>> it is a bug. I am not sure if that is something we should attempt to >>>>>>>> negotiate explicitly, or to make the element take a >>>>>>>> ?protocol? >>>>>>>> attribute? >>>>>>>>> >>>>>>>>> >>>>>>> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking. >>>>>>> >>>>>>>>> 2). Master is throwing the following exception: >>>>>>>>> >>>>>>>>> 22:15:25,094 INFO [org.jboss.as.process.Server:server-one.status] >>>>>>>>> (ProcessController-threads - 3) JBAS012017: Starting process >>>>>>>>> 'Server:server-one' >>>>>>>>> [Server:server-one] Error occurred during initialization of VM >>>>>>>>> [Server:server-one] Server VM is only supported on ARMv7+ VFP >>>>>>>> >>>>>>>> This ^^ seems to be the real error. Try removing ?-server? in the >>>>>>>> jvm-options. >>>>>>> >>>>>>> I removed -server from domain.sh, didn't realize its hardcoded in >>>>>>> host.xml. It worked after commenting in host.xml. Is that a bug as >>>>>>> well ? >>>>>>> >>>>>>> Arun >>>>>>> >>>>>>>>> 22:15:25,557 INFO [org.jboss.as.process.Server:server-one.status] >>>>>>>>> (reaper for Server:server-one) JBAS012010: Process >>>>>>>>> 'Server:server-one' >>>>>>>>> finished with an exit status of 1 >>>>>>>>> [Host Controller] 22:15:26,408 INFO [org.jboss.as.host.controller] >>>>>>>>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering >>>>>>>>> server server-one >>>>>>>>> [Host Controller] 22:15:26,495 INFO [org.jboss.as.host.controller] >>>>>>>>> (Controller Boot Thread) JBAS010922: Starting server server-two >>>>>>>>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status] >>>>>>>>> (ProcessController-threads - 3) JBAS012006: Failed to send data >>>>>>>>> bytes >>>>>>>>> to process 'Server:server-one' input stream: java.io.IOException: >>>>>>>>> Stream closed >>>>>>>>> at >>>>>>>>> >>>>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at java.io.OutputStream.write(OutputStream.java:116) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at >>>>>>>>> >>>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>>>>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection] >>>>>>>>> (ProcessController-threads - 3) JBAS016610: Failed to read a >>>>>>>>> message: >>>>>>>>> java.io.IOException: Stream closed >>>>>>>>> at >>>>>>>>> >>>>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at java.io.OutputStream.write(OutputStream.java:116) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at >>>>>>>>> >>>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) >>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2] >>>>>>>>> at >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>>>> [rt.jar:1.7.0_40] >>>>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] >>>>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>>>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >>>>>>>>> >>>>>>>>> Same error for server-two as well. >>>>>>>>> >>>>>>>>> Trying to explicitly start server-three on slave gives the same >>>>>>>>> error. >>>>>>>>> >>>>>>>>> This is all using 8.1 CR2. >>>>>>>>> >>>>>>>>> Any idea what might be wrong ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Aru >>>>>>>>> >>>>>>>>> -- >>>>>>>>> http://blog.arungupta.me >>>>>>>>> http://twitter.com/arungupta >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> http://blog.arungupta.me >>>>>>> http://twitter.com/arungupta >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://blog.arungupta.me >>>>>> http://twitter.com/arungupta >>>> >>>> >>> >>> >> > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Wed May 28 17:23:45 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 28 May 2014 16:23:45 -0500 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not Message-ID: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> So we noticed two problems with releasing the patch for 8.1.0.Final 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? If there is enough demand considering 1 & 2 I would be happy to release one. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Wed May 28 17:23:45 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 28 May 2014 16:23:45 -0500 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not Message-ID: So we noticed two problems with releasing the patch for 8.1.0.Final 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? If there is enough demand considering 1 & 2 I would be happy to release one. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From arun.gupta at gmail.com Wed May 28 17:24:10 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 28 May 2014 14:24:10 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> Message-ID: >> - Configure Domain Controller (master) on one Raspi >> - Configure Host Controller (slave) on another Raspi >> - Deploy an application to the cluster using jboss-cli > > Just in case this is a misconception, clustering and domain management are independent things. You don?t need one to do the other. For example see standalone-full-ha.xml. > Yes, understood :) >> >> However the session replication does not seem to work, i.e. session >> attributes added to HTTP session on master are not replicated to >> slave, and vice versa. How do I get that piece working ? > > Do you have distributable in your web.xml, and does the profile your server is using have session replication configured (e.g using the ha profile or the ha-full profile)? > Yes, to both. web.xml is at: https://github.com/arun-gupta/wildfly-samples/blob/master/clustering/http/src/main/webapp/WEB-INF/web.xml This WAR file shows sessions being replicated when two instances are created on the same host in other-server-group which points to full-ha profile. In both cases (instances on same host or instances as master/slave), the app is deployed to other-server-group. Does anything need to be explicitly configured for session replication when instances are on separate hosts ? FWIW I've been using port hopping to show session replication, without any LB in the front. Does that matter ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From dandread at redhat.com Wed May 28 17:48:05 2014 From: dandread at redhat.com (Dimitris Andreadis) Date: Wed, 28 May 2014 23:48:05 +0200 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> Message-ID: <53865995.1070800@redhat.com> IMO, if the patch is almost as big as the full distro itself, that kind of defeats the purpose. But you could provide both distros anyway and see from the download counts what people are actually interested in, and maybe get some feedback on the patch mechanism, itself. /Dimitris On 28/05/2014 23:23, Jason Greene wrote: > So we noticed two problems with releasing the patch for 8.1.0.Final > > 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. > 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). > > So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? > > If there is enough demand considering 1 & 2 I would be happy to release one. > > Thanks! > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From arun.gupta at gmail.com Wed May 28 18:13:23 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 28 May 2014 15:13:23 -0700 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <53865995.1070800@redhat.com> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> <53865995.1070800@redhat.com> Message-ID: +1 to Dimitris's suggestion. This would particularly allow us to test/explain the mechanism that will be used in future WildFly builds. Any plans for individual technology to do WildFly patch-compatible releases ? Arun On Wed, May 28, 2014 at 2:48 PM, Dimitris Andreadis wrote: > IMO, if the patch is almost as big as the full distro itself, that kind of defeats the > purpose. But you could provide both distros anyway and see from the download counts what > people are actually interested in, and maybe get some feedback on the patch mechanism, itself. > > /Dimitris > > On 28/05/2014 23:23, Jason Greene wrote: >> So we noticed two problems with releasing the patch for 8.1.0.Final >> >> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. >> 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). >> >> So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? >> >> If there is enough demand considering 1 & 2 I would be happy to release one. >> >> Thanks! >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- http://blog.arungupta.me http://twitter.com/arungupta From jperkins at redhat.com Wed May 28 20:12:36 2014 From: jperkins at redhat.com (James R. Perkins) Date: Wed, 28 May 2014 17:12:36 -0700 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <53865995.1070800@redhat.com> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> <53865995.1070800@redhat.com> Message-ID: <53867B74.6080109@redhat.com> +1 If both isn't a huge deal, I say both. On 05/28/2014 02:48 PM, Dimitris Andreadis wrote: > IMO, if the patch is almost as big as the full distro itself, that kind of defeats the > purpose. But you could provide both distros anyway and see from the download counts what > people are actually interested in, and maybe get some feedback on the patch mechanism, itself. > > /Dimitris > > On 28/05/2014 23:23, Jason Greene wrote: >> So we noticed two problems with releasing the patch for 8.1.0.Final >> >> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. >> 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). >> >> So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? >> >> If there is enough demand considering 1 & 2 I would be happy to release one. >> >> Thanks! >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat From vtunka at redhat.com Thu May 29 04:41:36 2014 From: vtunka at redhat.com (Vaclav Tunka) Date: Thu, 29 May 2014 10:41:36 +0200 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> <53865995.1070800@redhat.com> Message-ID: <5386F2C0.1090208@redhat.com> I agree with Dimitris as well. I am really looking forward for those per-class deltas. We should make sure we will ignore differences between various JDKs and associated compilers over various platforms. If I can help somehow, I will gladly do it. Cheers, Vaclav On 05/29/2014 12:13 AM, Arun Gupta wrote: > +1 to Dimitris's suggestion. This would particularly allow us to > test/explain the mechanism that will be used in future WildFly builds. > > Any plans for individual technology to do WildFly patch-compatible releases ? > > Arun > > On Wed, May 28, 2014 at 2:48 PM, Dimitris Andreadis wrote: >> IMO, if the patch is almost as big as the full distro itself, that kind of defeats the >> purpose. But you could provide both distros anyway and see from the download counts what >> people are actually interested in, and maybe get some feedback on the patch mechanism, itself. >> >> /Dimitris >> >> On 28/05/2014 23:23, Jason Greene wrote: >>> So we noticed two problems with releasing the patch for 8.1.0.Final >>> >>> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. >>> 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). >>> >>> So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? >>> >>> If there is enough demand considering 1 & 2 I would be happy to release one. >>> >>> Thanks! >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- Vaclav Tunka Enterprise Application Platforms JBoss by Red Hat From tomaz.cerar at gmail.com Thu May 29 04:56:11 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 29 May 2014 10:56:11 +0200 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> Message-ID: Lets do both. For many users I think having nice upgrade tool will help them move to newer version. Even if upgrading is mostly just copying standalone.xml over... Btw, what if we would provide two part patch? first one that would fix the jar invalidation and then proper one for 8.1 upgrade? On Wed, May 28, 2014 at 11:23 PM, Jason Greene wrote: > So we noticed two problems with releasing the patch for 8.1.0.Final > > 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final > ?disabling" jars, applying the 8.1 patch will lead to warnings, this is > fixed in their upcoming beta2 test. We have also removed the jar > ?disabling?, so future patches do not have this problem. > 2. It?s Big - Due to the breadth of change in this release, the size of > the patch is only slightly smaller than the distro. We have a planned > improvement to support finer grained, per-class deltas, which would greatly > reduce the size, but its not worth holding the release over (IMO). > > So the big question is assuming the above do you want a patch file for > 8.1, or just a full distro only this time, and we instead ship a patch in a > future 8.x release (we are considering doing an 8.2 with the CDI update > that was pulled out of 8.1 due to TCK rules)? > > If there is enough demand considering 1 & 2 I would be happy to release > one. > > Thanks! > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140529/96249bbb/attachment.html From darran.lofthouse at jboss.com Thu May 29 06:09:53 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 29 May 2014 11:09:53 +0100 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <53867B74.6080109@redhat.com> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> <53865995.1070800@redhat.com> <53867B74.6080109@redhat.com> Message-ID: <53870771.2090903@jboss.com> +1 If we have the capability I think we should be providing the option for it to be used. An additional point, size is not the only motivation for a patch - using a patch means the end users don't need to start with a clean install if they have an existing installation. Regards, Darran Lofthouse. On 29/05/14 01:12, James R. Perkins wrote: > +1 > > If both isn't a huge deal, I say both. > > On 05/28/2014 02:48 PM, Dimitris Andreadis wrote: >> IMO, if the patch is almost as big as the full distro itself, that kind of defeats the >> purpose. But you could provide both distros anyway and see from the download counts what >> people are actually interested in, and maybe get some feedback on the patch mechanism, itself. >> >> /Dimitris >> >> On 28/05/2014 23:23, Jason Greene wrote: >>> So we noticed two problems with releasing the patch for 8.1.0.Final >>> >>> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. >>> 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). >>> >>> So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? >>> >>> If there is enough demand considering 1 & 2 I would be happy to release one. >>> >>> Thanks! >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From kabir.khan at jboss.com Thu May 29 06:24:34 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 29 May 2014 11:24:34 +0100 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <53870771.2090903@jboss.com> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> <53865995.1070800@redhat.com> <53867B74.6080109@redhat.com> <53870771.2090903@jboss.com> Message-ID: <10E9EF55-0B85-44F6-BCA5-82A0E888D0E2@jboss.com> On 29 May 2014, at 11:09, Darran Lofthouse wrote: > +1 If we have the capability I think we should be providing the option > for it to be used. > > An additional point, size is not the only motivation for a patch - using > a patch means the end users don't need to start with a clean install if > they have an existing installation. Yes, apart from just standalone.xml, carrying over JDBC drivers (and probably other things I forget) should be useful too > > Regards, > Darran Lofthouse. > > > On 29/05/14 01:12, James R. Perkins wrote: >> +1 >> >> If both isn't a huge deal, I say both. >> >> On 05/28/2014 02:48 PM, Dimitris Andreadis wrote: >>> IMO, if the patch is almost as big as the full distro itself, that kind of defeats the >>> purpose. But you could provide both distros anyway and see from the download counts what >>> people are actually interested in, and maybe get some feedback on the patch mechanism, itself. >>> >>> /Dimitris >>> >>> On 28/05/2014 23:23, Jason Greene wrote: >>>> So we noticed two problems with releasing the patch for 8.1.0.Final >>>> >>>> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. >>>> 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). >>>> >>>> So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? >>>> >>>> If there is enough demand considering 1 & 2 I would be happy to release one. >>>> >>>> Thanks! >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Thu May 29 06:41:37 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 29 May 2014 11:41:37 +0100 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <10E9EF55-0B85-44F6-BCA5-82A0E888D0E2@jboss.com> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> <53865995.1070800@redhat.com> <53867B74.6080109@redhat.com> <53870771.2090903@jboss.com> <10E9EF55-0B85-44F6-BCA5-82A0E888D0E2@jboss.com> Message-ID: <53870EE1.3090302@jboss.com> On 29/05/14 11:24, Kabir Khan wrote: > > On 29 May 2014, at 11:09, Darran Lofthouse wrote: > >> +1 If we have the capability I think we should be providing the option >> for it to be used. >> >> An additional point, size is not the only motivation for a patch - using >> a patch means the end users don't need to start with a clean install if >> they have an existing installation. > Yes, apart from just standalone.xml, carrying over JDBC drivers (and probably other things I forget) should be useful too Deployments, vault instances, key and trust stores, properties files containing their users, integration as a service on their os, tweaked memory settings .... And I am sure I have missed another bunch of things an end user may have added to a clean distro ;-) >> >> Regards, >> Darran Lofthouse. >> >> >> On 29/05/14 01:12, James R. Perkins wrote: >>> +1 >>> >>> If both isn't a huge deal, I say both. >>> >>> On 05/28/2014 02:48 PM, Dimitris Andreadis wrote: >>>> IMO, if the patch is almost as big as the full distro itself, that kind of defeats the >>>> purpose. But you could provide both distros anyway and see from the download counts what >>>> people are actually interested in, and maybe get some feedback on the patch mechanism, itself. >>>> >>>> /Dimitris >>>> >>>> On 28/05/2014 23:23, Jason Greene wrote: >>>>> So we noticed two problems with releasing the patch for 8.1.0.Final >>>>> >>>>> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. >>>>> 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). >>>>> >>>>> So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? >>>>> >>>>> If there is enough demand considering 1 & 2 I would be happy to release one. >>>>> >>>>> Thanks! >>>>> -- >>>>> Jason T. Greene >>>>> WildFly Lead / JBoss EAP Platform Architect >>>>> JBoss, a division of Red Hat >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jgreene at redhat.com Thu May 29 08:29:03 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Thu, 29 May 2014 08:29:03 -0400 (EDT) Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> Message-ID: <097123F5-A051-435A-B94F-60CFC94B3ACE@redhat.com> > On May 29, 2014, at 3:56 AM, Toma? Cerar wrote: > > Lets do both. > > For many users I think having nice upgrade tool will help them move to newer version. Even if upgrading is mostly just copying standalone.xml over... > > Btw, what if we would provide two part patch? first one that would fix the jar invalidation and then proper one for 8.1 upgrade? > I like the optional fix up script idea a bit better because it would correct all of the old "disabled" jars. Although the 2 patch solution would have to be used in a future release for updating to the new format. We also should look into the possibility of dynamic bootstrapping of new patch behavior in the patch itself. This would allow us to introduce new formats without an intermediary patch. > >> On Wed, May 28, 2014 at 11:23 PM, Jason Greene wrote: >> So we noticed two problems with releasing the patch for 8.1.0.Final >> >> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final ?disabling" jars, applying the 8.1 patch will lead to warnings, this is fixed in their upcoming beta2 test. We have also removed the jar ?disabling?, so future patches do not have this problem. >> 2. It?s Big - Due to the breadth of change in this release, the size of the patch is only slightly smaller than the distro. We have a planned improvement to support finer grained, per-class deltas, which would greatly reduce the size, but its not worth holding the release over (IMO). >> >> So the big question is assuming the above do you want a patch file for 8.1, or just a full distro only this time, and we instead ship a patch in a future 8.x release (we are considering doing an 8.2 with the CDI update that was pulled out of 8.1 due to TCK rules)? >> >> If there is enough demand considering 1 & 2 I would be happy to release one. >> >> Thanks! >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140529/e3345fe7/attachment.html From anmiller at redhat.com Thu May 29 11:54:09 2014 From: anmiller at redhat.com (Andrig Miller) Date: Thu, 29 May 2014 11:54:09 -0400 (EDT) Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> Message-ID: <15156007.1794.1401378844238.JavaMail.andrig@worklaptop.miller.org> It would be nice, regardless of size of the patch, to get it out there, and let people try it out. The more usage we get for the patch mechanism, the better. Andy ----- Original Message ----- > From: "Jason Greene" > To: "WildFly Dev" > Sent: Wednesday, May 28, 2014 3:23:45 PM > Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not > > So we noticed two problems with releasing the patch for 8.1.0.Final > > 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final > ?disabling" jars, applying the 8.1 patch will lead to warnings, this > is fixed in their upcoming beta2 test. We have also removed the jar > ?disabling?, so future patches do not have this problem. > 2. It?s Big - Due to the breadth of change in this release, the size > of the patch is only slightly smaller than the distro. We have a > planned improvement to support finer grained, per-class deltas, > which would greatly reduce the size, but its not worth holding the > release over (IMO). > > So the big question is assuming the above do you want a patch file > for 8.1, or just a full distro only this time, and we instead ship a > patch in a future 8.x release (we are considering doing an 8.2 with > the CDI update that was pulled out of 8.1 due to TCK rules)? > > If there is enough demand considering 1 & 2 I would be happy to > release one. > > Thanks! > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Thu May 29 14:14:45 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 29 May 2014 13:14:45 -0500 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <15156007.1794.1401378844238.JavaMail.andrig@worklaptop.miller.org> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> <15156007.1794.1401378844238.JavaMail.andrig@worklaptop.miller.org> Message-ID: <494EBF2A-1745-4C07-980A-BE0B7055882A@redhat.com> Ok so the universal feedback is that we release the mega-patch anyway. On May 29, 2014, at 10:54 AM, Andrig Miller wrote: > It would be nice, regardless of size of the patch, to get it out there, and let people try it out. The more usage we get for the patch mechanism, the better. > > Andy > > ----- Original Message ----- >> From: "Jason Greene" >> To: "WildFly Dev" >> Sent: Wednesday, May 28, 2014 3:23:45 PM >> Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not >> >> So we noticed two problems with releasing the patch for 8.1.0.Final >> >> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final >> ?disabling" jars, applying the 8.1 patch will lead to warnings, this >> is fixed in their upcoming beta2 test. We have also removed the jar >> ?disabling?, so future patches do not have this problem. >> 2. It?s Big - Due to the breadth of change in this release, the size >> of the patch is only slightly smaller than the distro. We have a >> planned improvement to support finer grained, per-class deltas, >> which would greatly reduce the size, but its not worth holding the >> release over (IMO). >> >> So the big question is assuming the above do you want a patch file >> for 8.1, or just a full distro only this time, and we instead ship a >> patch in a future 8.x release (we are considering doing an 8.2 with >> the CDI update that was pulled out of 8.1 due to TCK rules)? >> >> If there is enough demand considering 1 & 2 I would be happy to >> release one. >> >> Thanks! >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Thu May 29 14:14:45 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 29 May 2014 13:14:45 -0500 Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not In-Reply-To: <15156007.1794.1401378844238.JavaMail.andrig@worklaptop.miller.org> References: <05403ABC-63E7-437A-A179-8B84A5E5F68C@redhat.com> <15156007.1794.1401378844238.JavaMail.andrig@worklaptop.miller.org> Message-ID: <293FE92A-C66C-4DFC-BEF7-21019D74C724@redhat.com> Ok so the universal feedback is that we release the mega-patch anyway. On May 29, 2014, at 10:54 AM, Andrig Miller wrote: > It would be nice, regardless of size of the patch, to get it out there, and let people try it out. The more usage we get for the patch mechanism, the better. > > Andy > > ----- Original Message ----- >> From: "Jason Greene" >> To: "WildFly Dev" >> Sent: Wednesday, May 28, 2014 3:23:45 PM >> Subject: [wildfly-dev] [POLL] 8.1 Patch Or Not >> >> So we noticed two problems with releasing the patch for 8.1.0.Final >> >> 1. JBoss Tools Issues - Due to the patching mechanism in 8.0.0.Final >> ?disabling" jars, applying the 8.1 patch will lead to warnings, this >> is fixed in their upcoming beta2 test. We have also removed the jar >> ?disabling?, so future patches do not have this problem. >> 2. It?s Big - Due to the breadth of change in this release, the size >> of the patch is only slightly smaller than the distro. We have a >> planned improvement to support finer grained, per-class deltas, >> which would greatly reduce the size, but its not worth holding the >> release over (IMO). >> >> So the big question is assuming the above do you want a patch file >> for 8.1, or just a full distro only this time, and we instead ship a >> patch in a future 8.x release (we are considering doing an 8.2 with >> the CDI update that was pulled out of 8.1 due to TCK rules)? >> >> If there is enough demand considering 1 & 2 I would be happy to >> release one. >> >> Thanks! >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From arun.gupta at gmail.com Thu May 29 16:06:13 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 29 May 2014 13:06:13 -0700 Subject: [wildfly-dev] --force and --server-groups Message-ID: Deploying a WAR file to a server-group gives ... [domain at 10.0.0.27:9990 /] deploy http-1.0-SNAPSHOT.war --server-groups=other-server-group 'http-1.0-SNAPSHOT.war' already exists in the deployment repository (use --force to replace the existing content in the repository). Specifying --force gives ... [domain at 10.0.0.27:9990 /] deploy http-1.0-SNAPSHOT.war --force --server-groups=other-server-group --force only replaces the content in the deployment repository and can't be used in combination with any of --disabled, --server-groups or --all-server-groups. How do I force deploy the WAR to a server-group using jboss-cli ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From jgreene at redhat.com Thu May 29 23:18:43 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Thu, 29 May 2014 23:18:43 -0400 (EDT) Subject: [wildfly-dev] --force and --server-groups In-Reply-To: References: Message-ID: <4EA11590-3AD9-4C47-8FCF-94611E5DBE11@redhat.com> Just omit the --server-groups option. When you do a force you are replacing the source that every group references, so they all have to redeploy and specify a subset of groups doesn't make sense. Sent from my iPhone > On May 29, 2014, at 3:06 PM, Arun Gupta wrote: > > Deploying a WAR file to a server-group gives ... > > [domain at 10.0.0.27:9990 /] deploy http-1.0-SNAPSHOT.war > --server-groups=other-server-group > 'http-1.0-SNAPSHOT.war' already exists in the deployment repository > (use --force to replace the existing content in the repository). > > Specifying --force gives ... > > [domain at 10.0.0.27:9990 /] deploy http-1.0-SNAPSHOT.war --force > --server-groups=other-server-group > --force only replaces the content in the deployment repository and > can't be used in combination with any of --disabled, --server-groups > or --all-server-groups. > > How do I force deploy the WAR to a server-group using jboss-cli ? > > Arun > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jgreene at redhat.com Thu May 29 23:22:46 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Thu, 29 May 2014 23:22:46 -0400 (EDT) Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> Message-ID: <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> Sent from my iPhone > On May 28, 2014, at 4:24 PM, Arun Gupta wrote: > > > FWIW I've been using port hopping to show session replication, without > any LB in the front. Does that matter ? Did you ever get help on this? I would double check that you can see replication events happening, perhaps it's still a network issue. Also you might want to verify your session cookie is actually matching both locations. You might have two different sessions. From arun.gupta at gmail.com Thu May 29 23:26:08 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 29 May 2014 20:26:08 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> Message-ID: On Thu, May 29, 2014 at 8:22 PM, Jason T. Greene wrote: > > > Sent from my iPhone > >> On May 28, 2014, at 4:24 PM, Arun Gupta wrote: >> >> >> FWIW I've been using port hopping to show session replication, without >> any LB in the front. Does that matter ? > > Did you ever get help on this? Nope. I've been able to install Apache2 on Raspi but seems like mod_cluster is not available for ARM. And so I've been trying to build mod_cluster on Raspi and now debugging: [ERROR] The project org.jboss:User-Guide-en:1.3.1.Final-SNAPSHOT (/home/pi/mod_cluster/mod_cluster/docs/userguide/pom.xml) has 2 errors [ERROR] Unresolveable build extension: Plugin org.jboss.maven.plugins:maven-jdocbook-plugin:2.1.2 or one of its dependencies could not be resolved: Failed to collect dependencies at org.jboss.maven.plugins:maven-jdocbook-plugin:jar:2.1.2 -> org.jboss:jbossorg-docbook-xslt:jar:1.1.0: Failed to read artifact descriptor for org.jboss:jbossorg-docbook-xslt:jar:1.1.0: Could not transfer artifact org.jboss:jbossorg-docbook-xslt:pom:1.1.0 from/to old jboss.org (http://repository.jboss.org/maven2): Access denied to: http://repository.jboss.org/maven2/org/jboss/jbossorg-docbook-xslt/1.1.0/jbossorg-docbook-xslt-1.1.0.pom , ReasonPhrase:Forbidden. -> [Help 2] [ERROR] Unknown packaging: jdocbook @ org.jboss:User-Guide-${translation}:1.3.1.Final-SNAPSHOT, /home/pi/mod_cluster/mod_cluster/docs/userguide/pom.xml, line 11, column 14 [ERROR] > > I would double check that you can see replication events happening, perhaps it's still a network issue. What log messages am I looking for ? > > Also you might want to verify your session cookie is actually matching both locations. You might have two different sessions. The session ids are indeed different. Just pushed out the latest blog in this series at: http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ The session id are shown towards the end in screen snapshots, and are indeed different. Arun -- http://blog.arungupta.me http://twitter.com/arungupta From andrei.tchijov at vgw.co Fri May 30 04:01:42 2014 From: andrei.tchijov at vgw.co (Andrei Tchijov) Date: Fri, 30 May 2014 10:01:42 +0200 Subject: [wildfly-dev] wildfly 8.1RC2 refuse to serve *.zip files (404) Message-ID: Hi, Sorry to bother (if this is wrong list to ask), but I wonder if anybody can help me with following problem: We have an application deployed on wildfly which among other things serves few static files (*.html, *.json and *.zip). Everything works as it should in 8.0.0Final. However, in 8.1RC2 - *.html and *.json files do work, but *.zip files report 404. ?Nothing changed on our side - the very same WAR file gets deployed in both cases. Your help will be highly appreciated, Cheers, Andrei Tchijov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140530/dfd4b39a/attachment.html From tomaz.cerar at gmail.com Fri May 30 05:30:46 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 30 May 2014 11:30:46 +0200 Subject: [wildfly-dev] wildfly 8.1RC2 refuse to serve *.zip files (404) In-Reply-To: References: Message-ID: Just add this config to your web.xml default io.undertow.servlet.handlers.DefaultServlet allowed-extensions js, css, png, jpg, gif, html, htm, txt, pdf, jpeg, xml, zip disallowed-extensions class, jar, war and modify allowed / disallowed extensions anyway you want On Fri, May 30, 2014 at 10:01 AM, Andrei Tchijov wrote: > Hi, > > Sorry to bother (if this is wrong list to ask), but I wonder if anybody > can help me with following problem: > > We have an application deployed on wildfly which among other things serves > few static files (*.html, *.json and *.zip). Everything works as it should > in 8.0.0Final. However, in 8.1RC2 - *.html and *.json files do work, but > *.zip files report 404. Nothing changed on our side - the very same WAR > file gets deployed in both cases. > > Your help will be highly appreciated, > > Cheers, > Andrei Tchijov > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140530/830e9a75/attachment.html From andrei.tchijov at vgw.co Fri May 30 06:11:01 2014 From: andrei.tchijov at vgw.co (Andrei Tchijov) Date: Fri, 30 May 2014 12:11:01 +0200 Subject: [wildfly-dev] wildfly 8.1RC2 refuse to serve *.zip files (404) In-Reply-To: References: Message-ID: Brilliant! Works like a champ! Cheers --? Andrei Tchijov On May 30, 2014 at 11:30:46 , Toma? Cerar (tomaz.cerar at gmail.com) wrote: Just add this config to your web.xml ????? default ????? io.undertow.servlet.handlers.DefaultServlet ????? ????????? allowed-extensions ????????? js, css, png, jpg, gif, html, htm, txt, pdf, jpeg, xml, zip ????? ????? ????????? disallowed-extensions ????????? class, jar, war ????? ????? ? and modify allowed / disallowed extensions anyway you want On Fri, May 30, 2014 at 10:01 AM, Andrei Tchijov wrote: Hi, Sorry to bother (if this is wrong list to ask), but I wonder if anybody can help me with following problem: We have an application deployed on wildfly which among other things serves few static files (*.html, *.json and *.zip). Everything works as it should in 8.0.0Final. However, in 8.1RC2 - *.html and *.json files do work, but *.zip files report 404. ?Nothing changed on our side - the very same WAR file gets deployed in both cases. Your help will be highly appreciated, Cheers, Andrei Tchijov _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140530/7b6e2856/attachment.html From asoldano at redhat.com Fri May 30 11:26:55 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Fri, 30 May 2014 17:26:55 +0200 Subject: [wildfly-dev] WFLY9 documentation area Message-ID: <5388A33F.9000709@redhat.com> Folks, should https://docs.jboss.org/author/display/WFLY8 be cloned into https://docs.jboss.org/author/display/WFLY9 ? Who can do that? The WS team needs to start updating the doc for the next WFLY version... Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From jason.greene at redhat.com Fri May 30 11:47:36 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 30 May 2014 10:47:36 -0500 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> Message-ID: <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> On May 29, 2014, at 10:26 PM, Arun Gupta wrote: > On Thu, May 29, 2014 at 8:22 PM, Jason T. Greene wrote: >> >> >> Sent from my iPhone >> >>> On May 28, 2014, at 4:24 PM, Arun Gupta wrote: >>> >>> >>> FWIW I've been using port hopping to show session replication, without >>> any LB in the front. Does that matter ? >> >> Did you ever get help on this? > > Nope. Ah your problem is the session id cookie domain (see below) > > I've been able to install Apache2 on Raspi but seems like mod_cluster > is not available for ARM. And so I've been trying to build mod_cluster > on Raspi and now debugging: > -snip- A couple other options that would be fun to play with: 1. Using Undertow?s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn?t set it): 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon) https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java (requires alteration for your topology) > > >> >> I would double check that you can see replication events happening, perhaps it's still a network issue. > > What log messages am I looking for ? You can just use wireshark (which has a jgroups decoder now i think), and look for traffic when you make changes, but this likely isn?t your problem. > >> >> Also you might want to verify your session cookie is actually matching both locations. You might have two different sessions. > > The session ids are indeed different. Just pushed out the latest blog > in this series at: > > http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ > > The session id are shown towards the end in screen snapshots, and are > indeed different. So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this: .example Then you want to add host entries to hosts: pi1.example 10.x.x.x pi2.example 10.x.x.x After you do that you should be able to stick pi1.example and pi2.example in the browser. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From rhusar at redhat.com Fri May 30 11:48:01 2014 From: rhusar at redhat.com (Radoslav Husar) Date: Fri, 30 May 2014 17:48:01 +0200 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> Message-ID: <5388A831.2090004@redhat.com> On 30/05/14 05:26, Arun Gupta wrote: > On Thu, May 29, 2014 at 8:22 PM, Jason T. Greene wrote: >> >> >> Sent from my iPhone >> >>> On May 28, 2014, at 4:24 PM, Arun Gupta wrote: >>> >>> >>> FWIW I've been using port hopping to show session replication, without >>> any LB in the front. Does that matter ? >> >> Did you ever get help on this? > > Nope. Sorry, I was on PTO so I missed the continuation of your thread. >> I would double check that you can see replication events happening, perhaps it's still a network issue. > > What log messages am I looking for ? You are looking for a message that you have a new cluster view that has 2 members, such as: 17:38:48,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 55) ISPN000094: Received new cluster view: [x220/web|1] (2) [x220/web, node2/web] >> Also you might want to verify your session cookie is actually matching both locations. You might have two different sessions. > > The session ids are indeed different. Just pushed out the latest blog > in this series at: > > http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ > > The session id are shown towards the end in screen snapshots, and are > indeed different. This is a common mistake. You need to think about how HTTP cookies work in the browser. If you create a session you are receiving a cookie, the browser is going to send that cookie that identifies that session only for the same *domain* (whole RFC and details here http://tools.ietf.org/html/rfc6265#page-16 ). Given your setup, the domains are 10.0.0.27 and 10.0.0.28, respectively. That means the domain is different and cookies will *not* be sent and thus a new session will be created. If you were to use port offsetting it's a whole different story, same as when you are switching from HTTP/80 to HTTPS/443 you keep your session (watch out for secure cookies though). To test, you either need to spoof the cookie (e.g. in the WF testsuite we are using a HTTP client that overrides the domain matching logic to be relaxed) or use a loadbalancer like mod_proxy or mod_cluster and then the domain will be the address of the loadbalancer. So what you are seeing is correct and expected behavior. Cheers, Rado From arun.gupta at gmail.com Fri May 30 13:54:38 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 30 May 2014 10:54:38 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> Message-ID: > > A couple other options that would be fun to play with: > > 1. Using Undertow?s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn?t set it): > > > > > Where will I add this fragment ? > > 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon) > > https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java > > (requires alteration for your topology) OK, let me try the simpler route first. I'm having issues building mod_cluster on ARM and following up on that separately. Seems like I may have to use mod_proxy for now since this is baked into Apache2 for ARM. >> The session ids are indeed different. Just pushed out the latest blog >> in this series at: >> >> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ >> >> The session id are shown towards the end in screen snapshots, and are >> indeed different. > > So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this: > > > .example > Can this element be added to domain.xml as well for the managed domain mode ? > > Then you want to add host entries to hosts: > > pi1.example 10.x.x.x > pi2.example 10.x.x.x These entries would be made in each individual /etc/hosts ? Arun > > > After you do that you should be able to stick pi1.example and pi2.example in the browser. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- http://blog.arungupta.me http://twitter.com/arungupta From jason.greene at redhat.com Fri May 30 14:27:20 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 30 May 2014 13:27:20 -0500 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> Message-ID: <2D5DED6C-263A-44DC-98F0-615EDA8E8766@redhat.com> On May 30, 2014, at 12:54 PM, Arun Gupta wrote: >> >> A couple other options that would be fun to play with: >> >> 1. Using Undertow?s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn?t set it): >> >> >> >> >> > > Where will I add this fragment ? In your domain.xml define a new profile called proxy, which is derived from the ?default" profile. In your new profile under the undertow subsystem, in the handlers section, below the welcome content file handler, add the above proxy config. You then need to change the location name=?/? to point to the ?reverse-proxy? handler (instead of ?welcome-content?) You basically want 3 server instances, one proxy, web server 1, and web server 2, all preferably on separate systems. The proxy would be assigned the proxy profile, the two other servers would get ha profiles. You could have your DC collocated on the proxy or on a separate box. You need to be sure that your instance-id matches the jvm route on the web 1 and 2 boxes (defaults to hostname) for sticky sessions to work properly. If you look at the cookie value you will see the jvmroute as a suffix. > >> >> 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon) >> >> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java >> >> (requires alteration for your topology) > OK, let me try the simpler route first. > > I'm having issues building mod_cluster on ARM and following up on that > separately. Seems like I may have to use mod_proxy for now since this > is baked into Apache2 for ARM. > >>> The session ids are indeed different. Just pushed out the latest blog >>> in this series at: >>> >>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ >>> >>> The session id are shown towards the end in screen snapshots, and are >>> indeed different. >> >> So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this: >> >> >> .example >> > > Can this element be added to domain.xml as well for the managed domain mode ? Yes next to the ?server? block inside the undertow subsystem you can add: Although note that you ONLY have to do this if you are not using an LB. > >> >> Then you want to add host entries to hosts: >> >> pi1.example 10.x.x.x >> pi2.example 10.x.x.x > > These entries would be made in each individual /etc/hosts ? You just need this on the machine with the client browser, so that when it sends HTTP requests it does ?Host: pi1.example? instead of "Host: 10.xxxxx?. If you decide to go the LB route, and want to have name references then you could do them everywhere to make it all easy. > > Arun > >> >> >> After you do that you should be able to stick pi1.example and pi2.example in the browser. >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From arun.gupta at gmail.com Fri May 30 19:44:43 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 30 May 2014 16:44:43 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <2D5DED6C-263A-44DC-98F0-615EDA8E8766@redhat.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> <2D5DED6C-263A-44DC-98F0-615EDA8E8766@redhat.com> Message-ID: I almost have 3 raspis (Apache, Domain Controller, Host Controller) now working and can see session replication happening. Had to use mod_proxy because building mod_cluster is involving. One (hopefully) last bit... How/where do I set the sticky session ? Arun On Fri, May 30, 2014 at 11:27 AM, Jason Greene wrote: > > On May 30, 2014, at 12:54 PM, Arun Gupta wrote: > >>> >>> A couple other options that would be fun to play with: >>> >>> 1. Using Undertow?s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn?t set it): >>> >>> >>> >>> >>> >> >> Where will I add this fragment ? > > In your domain.xml define a new profile called proxy, which is derived from the ?default" profile. > > In your new profile under the undertow subsystem, in the handlers section, below the welcome content file handler, add the above proxy config. You then need to change the location name=?/? to point to the ?reverse-proxy? handler (instead of ?welcome-content?) > > You basically want 3 server instances, one proxy, web server 1, and web server 2, all preferably on separate systems. The proxy would be assigned the proxy profile, the two other servers would get ha profiles. > > You could have your DC collocated on the proxy or on a separate box. You need to be sure that your instance-id matches the jvm route on the web 1 and 2 boxes (defaults to hostname) for sticky sessions to work properly. If you look at the cookie value you will see the jvmroute as a suffix. > >> >>> >>> 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon) >>> >>> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java >>> >>> (requires alteration for your topology) >> OK, let me try the simpler route first. >> >> I'm having issues building mod_cluster on ARM and following up on that >> separately. Seems like I may have to use mod_proxy for now since this >> is baked into Apache2 for ARM. >> >>>> The session ids are indeed different. Just pushed out the latest blog >>>> in this series at: >>>> >>>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ >>>> >>>> The session id are shown towards the end in screen snapshots, and are >>>> indeed different. >>> >>> So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this: >>> >>> >>> .example >>> >> >> Can this element be added to domain.xml as well for the managed domain mode ? > > Yes next to the ?server? block inside the undertow subsystem you can add: > > > > > > Although note that you ONLY have to do this if you are not using an LB. > >> >>> >>> Then you want to add host entries to hosts: >>> >>> pi1.example 10.x.x.x >>> pi2.example 10.x.x.x >> >> These entries would be made in each individual /etc/hosts ? > > You just need this on the machine with the client browser, so that when it sends HTTP requests it does ?Host: pi1.example? instead of "Host: 10.xxxxx?. > > If you decide to go the LB route, and want to have name references then you could do them everywhere to make it all easy. > >> >> Arun >> >>> >>> >>> After you do that you should be able to stick pi1.example and pi2.example in the browser. >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >> >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- http://blog.arungupta.me http://twitter.com/arungupta From arun.gupta at gmail.com Fri May 30 19:46:03 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 30 May 2014 16:46:03 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <5388A831.2090004@redhat.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <5388A831.2090004@redhat.com> Message-ID: >> >> The session ids are indeed different. Just pushed out the latest blog >> in this series at: >> >> >> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ >> >> The session id are shown towards the end in screen snapshots, and are >> indeed different. > > > This is a common mistake. You need to think about how HTTP cookies work in > the browser. If you create a session you are receiving a cookie, the browser > is going to send that cookie that identifies that session only for the same > *domain* (whole RFC and details here > http://tools.ietf.org/html/rfc6265#page-16 ). > > Given your setup, the domains are 10.0.0.27 and 10.0.0.28, respectively. > That means the domain is different and cookies will *not* be sent and thus a > new session will be created. > > If you were to use port offsetting it's a whole different story, same as > when you are switching from HTTP/80 to HTTPS/443 you keep your session > (watch out for secure cookies though). > > To test, you either need to spoof the cookie (e.g. in the WF testsuite we > are using a HTTP client that overrides the domain matching logic to be > relaxed) or use a loadbalancer like mod_proxy or mod_cluster and then the > domain will be the address of the loadbalancer. > > So what you are seeing is correct and expected behavior. This was it. After setting up the LB, and accessing the pages through LB shows the intended behavior. Arun > > Cheers, > Rado -- http://blog.arungupta.me http://twitter.com/arungupta From jgreene at redhat.com Fri May 30 20:58:10 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Fri, 30 May 2014 20:58:10 -0400 (EDT) Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> <2D5DED6C-263A-44DC-98F0-615EDA8E8766@redhat.com> Message-ID: Sent from my iPhone > On May 30, 2014, at 6:44 PM, Arun Gupta wrote: > > One (hopefully) last bit... > > How/where do I set the sticky session ? If you are using mod_proxy there is a memory based sticky session parameter you have to set to JSESSIONID, see the apache page. > > Arun > >> On Fri, May 30, 2014 at 11:27 AM, Jason Greene wrote: >> >> On May 30, 2014, at 12:54 PM, Arun Gupta wrote: >> >>>> >>>> A couple other options that would be fun to play with: >>>> >>>> 1. Using Undertow?s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn?t set it): >>>> >>>> >>>> >>>> >>>> >>> >>> Where will I add this fragment ? >> >> In your domain.xml define a new profile called proxy, which is derived from the ?default" profile. >> >> In your new profile under the undertow subsystem, in the handlers section, below the welcome content file handler, add the above proxy config. You then need to change the location name=?/? to point to the ?reverse-proxy? handler (instead of ?welcome-content?) >> >> You basically want 3 server instances, one proxy, web server 1, and web server 2, all preferably on separate systems. The proxy would be assigned the proxy profile, the two other servers would get ha profiles. >> >> You could have your DC collocated on the proxy or on a separate box. You need to be sure that your instance-id matches the jvm route on the web 1 and 2 boxes (defaults to hostname) for sticky sessions to work properly. If you look at the cookie value you will see the jvmroute as a suffix. >> >>> >>>> >>>> 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon) >>>> >>>> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java >>>> >>>> (requires alteration for your topology) >>> OK, let me try the simpler route first. >>> >>> I'm having issues building mod_cluster on ARM and following up on that >>> separately. Seems like I may have to use mod_proxy for now since this >>> is baked into Apache2 for ARM. >>> >>>>> The session ids are indeed different. Just pushed out the latest blog >>>>> in this series at: >>>>> >>>>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ >>>>> >>>>> The session id are shown towards the end in screen snapshots, and are >>>>> indeed different. >>>> >>>> So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this: >>>> >>>> >>>> .example >>>> >>> >>> Can this element be added to domain.xml as well for the managed domain mode ? >> >> Yes next to the ?server? block inside the undertow subsystem you can add: >> >> >> >> >> >> Although note that you ONLY have to do this if you are not using an LB. >> >>> >>>> >>>> Then you want to add host entries to hosts: >>>> >>>> pi1.example 10.x.x.x >>>> pi2.example 10.x.x.x >>> >>> These entries would be made in each individual /etc/hosts ? >> >> You just need this on the machine with the client browser, so that when it sends HTTP requests it does ?Host: pi1.example? instead of "Host: 10.xxxxx?. >> >> If you decide to go the LB route, and want to have name references then you could do them everywhere to make it all easy. >> >>> >>> Arun >>> >>>> >>>> >>>> After you do that you should be able to stick pi1.example and pi2.example in the browser. >>>> >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>> >>> >>> >>> -- >>> http://blog.arungupta.me >>> http://twitter.com/arungupta >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta From arun.gupta at gmail.com Sat May 31 00:10:41 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 30 May 2014 21:10:41 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> <2D5DED6C-263A-44DC-98F0-615EDA8E8766@redhat.com> Message-ID: And finally, the three-part article showing how to setup WildFly cluster on Raspberry Pi is now available at: http://blog.arungupta.me/2014/05/wildfly-cluster-raspberrypi-techtip28/ Feedback always welcome! Weekend can now start :) Cheers Arun On Fri, May 30, 2014 at 5:58 PM, Jason T. Greene wrote: > > > Sent from my iPhone > >> On May 30, 2014, at 6:44 PM, Arun Gupta wrote: >> >> One (hopefully) last bit... >> >> How/where do I set the sticky session ? > > If you are using mod_proxy there is a memory based sticky session parameter you have to set to JSESSIONID, see the apache page. > > >> >> Arun >> >>> On Fri, May 30, 2014 at 11:27 AM, Jason Greene wrote: >>> >>> On May 30, 2014, at 12:54 PM, Arun Gupta wrote: >>> >>>>> >>>>> A couple other options that would be fun to play with: >>>>> >>>>> 1. Using Undertow?s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn?t set it): >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> Where will I add this fragment ? >>> >>> In your domain.xml define a new profile called proxy, which is derived from the ?default" profile. >>> >>> In your new profile under the undertow subsystem, in the handlers section, below the welcome content file handler, add the above proxy config. You then need to change the location name=?/? to point to the ?reverse-proxy? handler (instead of ?welcome-content?) >>> >>> You basically want 3 server instances, one proxy, web server 1, and web server 2, all preferably on separate systems. The proxy would be assigned the proxy profile, the two other servers would get ha profiles. >>> >>> You could have your DC collocated on the proxy or on a separate box. You need to be sure that your instance-id matches the jvm route on the web 1 and 2 boxes (defaults to hostname) for sticky sessions to work properly. If you look at the cookie value you will see the jvmroute as a suffix. >>> >>>> >>>>> >>>>> 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon) >>>>> >>>>> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java >>>>> >>>>> (requires alteration for your topology) >>>> OK, let me try the simpler route first. >>>> >>>> I'm having issues building mod_cluster on ARM and following up on that >>>> separately. Seems like I may have to use mod_proxy for now since this >>>> is baked into Apache2 for ARM. >>>> >>>>>> The session ids are indeed different. Just pushed out the latest blog >>>>>> in this series at: >>>>>> >>>>>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ >>>>>> >>>>>> The session id are shown towards the end in screen snapshots, and are >>>>>> indeed different. >>>>> >>>>> So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this: >>>>> >>>>> >>>>> .example >>>>> >>>> >>>> Can this element be added to domain.xml as well for the managed domain mode ? >>> >>> Yes next to the ?server? block inside the undertow subsystem you can add: >>> >>> >>> >>> >>> >>> Although note that you ONLY have to do this if you are not using an LB. >>> >>>> >>>>> >>>>> Then you want to add host entries to hosts: >>>>> >>>>> pi1.example 10.x.x.x >>>>> pi2.example 10.x.x.x >>>> >>>> These entries would be made in each individual /etc/hosts ? >>> >>> You just need this on the machine with the client browser, so that when it sends HTTP requests it does ?Host: pi1.example? instead of "Host: 10.xxxxx?. >>> >>> If you decide to go the LB route, and want to have name references then you could do them everywhere to make it all easy. >>> >>>> >>>> Arun >>>> >>>>> >>>>> >>>>> After you do that you should be able to stick pi1.example and pi2.example in the browser. >>>>> >>>>> -- >>>>> Jason T. Greene >>>>> WildFly Lead / JBoss EAP Platform Architect >>>>> JBoss, a division of Red Hat >>>> >>>> >>>> >>>> -- >>>> http://blog.arungupta.me >>>> http://twitter.com/arungupta >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >> >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta -- http://blog.arungupta.me http://twitter.com/arungupta From kabir.khan at jboss.com Sat May 31 04:29:03 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Sat, 31 May 2014 09:29:03 +0100 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> <2D5DED6C-263A-44DC-98F0-615EDA8E8766@redhat.com> ! Message-ID: <975729B1-39EF-40C1-82A0-BE68795836E9@jboss.com> Nice! On 31 May 2014, at 05:10, Arun Gupta wrote: > And finally, the three-part article showing how to setup WildFly > cluster on Raspberry Pi is now available at: > > http://blog.arungupta.me/2014/05/wildfly-cluster-raspberrypi-techtip28/ > > Feedback always welcome! > > Weekend can now start :) > > Cheers > Arun > > > On Fri, May 30, 2014 at 5:58 PM, Jason T. Greene wrote: >> >> >> Sent from my iPhone >> >>> On May 30, 2014, at 6:44 PM, Arun Gupta wrote: >>> >>> One (hopefully) last bit... >>> >>> How/where do I set the sticky session ? >> >> If you are using mod_proxy there is a memory based sticky session parameter you have to set to JSESSIONID, see the apache page. >> >> >>> >>> Arun >>> >>>> On Fri, May 30, 2014 at 11:27 AM, Jason Greene wrote: >>>> >>>> On May 30, 2014, at 12:54 PM, Arun Gupta wrote: >>>> >>>>>> >>>>>> A couple other options that would be fun to play with: >>>>>> >>>>>> 1. Using Undertow?s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn?t set it): >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Where will I add this fragment ? >>>> >>>> In your domain.xml define a new profile called proxy, which is derived from the ?default" profile. >>>> >>>> In your new profile under the undertow subsystem, in the handlers section, below the welcome content file handler, add the above proxy config. You then need to change the location name=?/? to point to the ?reverse-proxy? handler (instead of ?welcome-content?) >>>> >>>> You basically want 3 server instances, one proxy, web server 1, and web server 2, all preferably on separate systems. The proxy would be assigned the proxy profile, the two other servers would get ha profiles. >>>> >>>> You could have your DC collocated on the proxy or on a separate box. You need to be sure that your instance-id matches the jvm route on the web 1 and 2 boxes (defaults to hostname) for sticky sessions to work properly. If you look at the cookie value you will see the jvmroute as a suffix. >>>> >>>>> >>>>>> >>>>>> 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon) >>>>>> >>>>>> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java >>>>>> >>>>>> (requires alteration for your topology) >>>>> OK, let me try the simpler route first. >>>>> >>>>> I'm having issues building mod_cluster on ARM and following up on that >>>>> separately. Seems like I may have to use mod_proxy for now since this >>>>> is baked into Apache2 for ARM. >>>>> >>>>>>> The session ids are indeed different. Just pushed out the latest blog >>>>>>> in this series at: >>>>>>> >>>>>>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ >>>>>>> >>>>>>> The session id are shown towards the end in screen snapshots, and are >>>>>>> indeed different. >>>>>> >>>>>> So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this: >>>>>> >>>>>> >>>>>> .example >>>>>> >>>>> >>>>> Can this element be added to domain.xml as well for the managed domain mode ? >>>> >>>> Yes next to the ?server? block inside the undertow subsystem you can add: >>>> >>>> >>>> >>>> >>>> >>>> Although note that you ONLY have to do this if you are not using an LB. >>>> >>>>> >>>>>> >>>>>> Then you want to add host entries to hosts: >>>>>> >>>>>> pi1.example 10.x.x.x >>>>>> pi2.example 10.x.x.x >>>>> >>>>> These entries would be made in each individual /etc/hosts ? >>>> >>>> You just need this on the machine with the client browser, so that when it sends HTTP requests it does ?Host: pi1.example? instead of "Host: 10.xxxxx?. >>>> >>>> If you decide to go the LB route, and want to have name references then you could do them everywhere to make it all easy. >>>> >>>>> >>>>> Arun >>>>> >>>>>> >>>>>> >>>>>> After you do that you should be able to stick pi1.example and pi2.example in the browser. >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>> JBoss, a division of Red Hat >>>>> >>>>> >>>>> >>>>> -- >>>>> http://blog.arungupta.me >>>>> http://twitter.com/arungupta >>>> >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>> >>> >>> >>> -- >>> http://blog.arungupta.me >>> http://twitter.com/arungupta > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta From daviaro at gmail.com Sat May 31 10:47:58 2014 From: daviaro at gmail.com (David Aroca) Date: Sat, 31 May 2014 09:47:58 -0500 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: <975729B1-39EF-40C1-82A0-BE68795836E9@jboss.com> References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> <2D5DED6C-263A-44DC-98F0-615EDA8E8766@redhat.com> <975729B1-39EF-40C1-82A0-BE68795836E9@jboss.com> Message-ID: Thnks Arun! 2014-05-31 3:29 GMT-05:00 Kabir Khan : > Nice! > On 31 May 2014, at 05:10, Arun Gupta wrote: > > > And finally, the three-part article showing how to setup WildFly > > cluster on Raspberry Pi is now available at: > > > > http://blog.arungupta.me/2014/05/wildfly-cluster-raspberrypi-techtip28/ > > > > Feedback always welcome! > > > > Weekend can now start :) > > > > Cheers > > Arun > > > > > > On Fri, May 30, 2014 at 5:58 PM, Jason T. Greene > wrote: > >> > >> > >> Sent from my iPhone > >> > >>> On May 30, 2014, at 6:44 PM, Arun Gupta wrote: > >>> > >>> One (hopefully) last bit... > >>> > >>> How/where do I set the sticky session ? > >> > >> If you are using mod_proxy there is a memory based sticky session > parameter you have to set to JSESSIONID, see the apache page. > >> > >> > >>> > >>> Arun > >>> > >>>> On Fri, May 30, 2014 at 11:27 AM, Jason Greene < > jason.greene at redhat.com> wrote: > >>>> > >>>> On May 30, 2014, at 12:54 PM, Arun Gupta > wrote: > >>>> > >>>>>> > >>>>>> A couple other options that would be fun to play with: > >>>>>> > >>>>>> 1. Using Undertow?s reverse proxy like this (assuming you named the > nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to > the host name if you didn?t set it): > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> Where will I add this fragment ? > >>>> > >>>> In your domain.xml define a new profile called proxy, which is > derived from the ?default" profile. > >>>> > >>>> In your new profile under the undertow subsystem, in the handlers > section, below the welcome content file handler, add the above proxy > config. You then need to change the location name=?/? to point to the > ?reverse-proxy? handler (instead of ?welcome-content?) > >>>> > >>>> You basically want 3 server instances, one proxy, web server 1, and > web server 2, all preferably on separate systems. The proxy would be > assigned the proxy profile, the two other servers would get ha profiles. > >>>> > >>>> You could have your DC collocated on the proxy or on a separate box. > You need to be sure that your instance-id matches the jvm route on the web > 1 and 2 boxes (defaults to hostname) for sticky sessions to work properly. > If you look at the cookie value you will see the jvmroute as a suffix. > >>>> > >>>>> > >>>>>> > >>>>>> 2. You could also use undertow 1.1 standalone which has a > mod_cluster impl (coming to WildFly soon) > >>>>>> > >>>>>> > https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java > >>>>>> > >>>>>> (requires alteration for your topology) > >>>>> OK, let me try the simpler route first. > >>>>> > >>>>> I'm having issues building mod_cluster on ARM and following up on > that > >>>>> separately. Seems like I may have to use mod_proxy for now since this > >>>>> is baked into Apache2 for ARM. > >>>>> > >>>>>>> The session ids are indeed different. Just pushed out the latest > blog > >>>>>>> in this series at: > >>>>>>> > >>>>>>> > http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ > >>>>>>> > >>>>>>> The session id are shown towards the end in screen snapshots, and > are > >>>>>>> indeed different. > >>>>>> > >>>>>> So the problem is you need to either have a shared cookie domain, > or use an LB, since the cookie domain has to match the URL for the browser > to send the same cookie. You can do this in either the global config > (standalone.xml under servlet-container), or you can add a setting to your > web.xml like this: > >>>>>> > >>>>>> > >>>>>> .example > >>>>>> > >>>>> > >>>>> Can this element be added to domain.xml as well for the managed > domain mode ? > >>>> > >>>> Yes next to the ?server? block inside the undertow subsystem you can > add: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Although note that you ONLY have to do this if you are not using an > LB. > >>>> > >>>>> > >>>>>> > >>>>>> Then you want to add host entries to hosts: > >>>>>> > >>>>>> pi1.example 10.x.x.x > >>>>>> pi2.example 10.x.x.x > >>>>> > >>>>> These entries would be made in each individual /etc/hosts ? > >>>> > >>>> You just need this on the machine with the client browser, so that > when it sends HTTP requests it does ?Host: pi1.example? instead of "Host: > 10.xxxxx?. > >>>> > >>>> If you decide to go the LB route, and want to have name references > then you could do them everywhere to make it all easy. > >>>> > >>>>> > >>>>> Arun > >>>>> > >>>>>> > >>>>>> > >>>>>> After you do that you should be able to stick pi1.example and > pi2.example in the browser. > >>>>>> > >>>>>> -- > >>>>>> Jason T. Greene > >>>>>> WildFly Lead / JBoss EAP Platform Architect > >>>>>> JBoss, a division of Red Hat > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> http://blog.arungupta.me > >>>>> http://twitter.com/arungupta > >>>> > >>>> -- > >>>> Jason T. Greene > >>>> WildFly Lead / JBoss EAP Platform Architect > >>>> JBoss, a division of Red Hat > >>> > >>> > >>> > >>> -- > >>> http://blog.arungupta.me > >>> http://twitter.com/arungupta > > > > > > > > -- > > http://blog.arungupta.me > > http://twitter.com/arungupta > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140531/574e3a59/attachment-0001.html From arun.gupta at gmail.com Sat May 31 21:37:57 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Sat, 31 May 2014 18:37:57 -0700 Subject: [wildfly-dev] 2 instance cluster in master/slave In-Reply-To: References: <8B504D45-944D-4D3A-BF75-769DE8EF2167@jboss.com> <5385DDE5.90704@redhat.com> <5385E4D5.9080803@redhat.com> <5605C912-EFDA-476C-8689-A596391E010F@redhat.com> <0FC395B8-AEEF-457B-87D5-6A9F13F624CC@redhat.com> <2D5DED6C-263A-44DC-98F0-615EDA8E8766@redhat.com> <975729B1-39EF-40C1-82A0-BE68795836E9@jboss.com> Message-ID: Please help spread the word. Let me know if you have fun ideas/projects that should run on Raspi and help us build thought leadership :-) Arun On Sat, May 31, 2014 at 7:47 AM, David Aroca wrote: > Thnks Arun! > > > 2014-05-31 3:29 GMT-05:00 Kabir Khan : >> >> Nice! >> On 31 May 2014, at 05:10, Arun Gupta wrote: >> >> > And finally, the three-part article showing how to setup WildFly >> > cluster on Raspberry Pi is now available at: >> > >> > http://blog.arungupta.me/2014/05/wildfly-cluster-raspberrypi-techtip28/ >> > >> > Feedback always welcome! >> > >> > Weekend can now start :) >> > >> > Cheers >> > Arun >> > >> > >> > On Fri, May 30, 2014 at 5:58 PM, Jason T. Greene >> > wrote: >> >> >> >> >> >> Sent from my iPhone >> >> >> >>> On May 30, 2014, at 6:44 PM, Arun Gupta wrote: >> >>> >> >>> One (hopefully) last bit... >> >>> >> >>> How/where do I set the sticky session ? >> >> >> >> If you are using mod_proxy there is a memory based sticky session >> >> parameter you have to set to JSESSIONID, see the apache page. >> >> >> >> >> >>> >> >>> Arun >> >>> >> >>>> On Fri, May 30, 2014 at 11:27 AM, Jason Greene >> >>>> wrote: >> >>>> >> >>>> On May 30, 2014, at 12:54 PM, Arun Gupta >> >>>> wrote: >> >>>> >> >>>>>> >> >>>>>> A couple other options that would be fun to play with: >> >>>>>> >> >>>>>> 1. Using Undertow?s reverse proxy like this (assuming you named the >> >>>>>> nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to >> >>>>>> the host name if you didn?t set it): >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> Where will I add this fragment ? >> >>>> >> >>>> In your domain.xml define a new profile called proxy, which is >> >>>> derived from the ?default" profile. >> >>>> >> >>>> In your new profile under the undertow subsystem, in the handlers >> >>>> section, below the welcome content file handler, add the above proxy config. >> >>>> You then need to change the location name=?/? to point to the >> >>>> ?reverse-proxy? handler (instead of ?welcome-content?) >> >>>> >> >>>> You basically want 3 server instances, one proxy, web server 1, and >> >>>> web server 2, all preferably on separate systems. The proxy would be >> >>>> assigned the proxy profile, the two other servers would get ha profiles. >> >>>> >> >>>> You could have your DC collocated on the proxy or on a separate box. >> >>>> You need to be sure that your instance-id matches the jvm route on the web 1 >> >>>> and 2 boxes (defaults to hostname) for sticky sessions to work properly. If >> >>>> you look at the cookie value you will see the jvmroute as a suffix. >> >>>> >> >>>>> >> >>>>>> >> >>>>>> 2. You could also use undertow 1.1 standalone which has a >> >>>>>> mod_cluster impl (coming to WildFly soon) >> >>>>>> >> >>>>>> >> >>>>>> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java >> >>>>>> >> >>>>>> (requires alteration for your topology) >> >>>>> OK, let me try the simpler route first. >> >>>>> >> >>>>> I'm having issues building mod_cluster on ARM and following up on >> >>>>> that >> >>>>> separately. Seems like I may have to use mod_proxy for now since >> >>>>> this >> >>>>> is baked into Apache2 for ARM. >> >>>>> >> >>>>>>> The session ids are indeed different. Just pushed out the latest >> >>>>>>> blog >> >>>>>>> in this series at: >> >>>>>>> >> >>>>>>> >> >>>>>>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/ >> >>>>>>> >> >>>>>>> The session id are shown towards the end in screen snapshots, and >> >>>>>>> are >> >>>>>>> indeed different. >> >>>>>> >> >>>>>> So the problem is you need to either have a shared cookie domain, >> >>>>>> or use an LB, since the cookie domain has to match the URL for the browser >> >>>>>> to send the same cookie. You can do this in either the global config >> >>>>>> (standalone.xml under servlet-container), or you can add a setting to your >> >>>>>> web.xml like this: >> >>>>>> >> >>>>>> >> >>>>>> .example >> >>>>>> >> >>>>> >> >>>>> Can this element be added to domain.xml as well for the managed >> >>>>> domain mode ? >> >>>> >> >>>> Yes next to the ?server? block inside the undertow subsystem you can >> >>>> add: >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Although note that you ONLY have to do this if you are not using an >> >>>> LB. >> >>>> >> >>>>> >> >>>>>> >> >>>>>> Then you want to add host entries to hosts: >> >>>>>> >> >>>>>> pi1.example 10.x.x.x >> >>>>>> pi2.example 10.x.x.x >> >>>>> >> >>>>> These entries would be made in each individual /etc/hosts ? >> >>>> >> >>>> You just need this on the machine with the client browser, so that >> >>>> when it sends HTTP requests it does ?Host: pi1.example? instead of "Host: >> >>>> 10.xxxxx?. >> >>>> >> >>>> If you decide to go the LB route, and want to have name references >> >>>> then you could do them everywhere to make it all easy. >> >>>> >> >>>>> >> >>>>> Arun >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> After you do that you should be able to stick pi1.example and >> >>>>>> pi2.example in the browser. >> >>>>>> >> >>>>>> -- >> >>>>>> Jason T. Greene >> >>>>>> WildFly Lead / JBoss EAP Platform Architect >> >>>>>> JBoss, a division of Red Hat >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> http://blog.arungupta.me >> >>>>> http://twitter.com/arungupta >> >>>> >> >>>> -- >> >>>> Jason T. Greene >> >>>> WildFly Lead / JBoss EAP Platform Architect >> >>>> JBoss, a division of Red Hat >> >>> >> >>> >> >>> >> >>> -- >> >>> http://blog.arungupta.me >> >>> http://twitter.com/arungupta >> > >> > >> > >> > -- >> > http://blog.arungupta.me >> > http://twitter.com/arungupta >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- http://blog.arungupta.me http://twitter.com/arungupta