From sanne at hibernate.org Fri Aug 1 06:58:31 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 1 Aug 2014 11:58:31 +0100 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users Message-ID: Currently users wishing for Search super-powers in their Hibernate applications need to enable the module explicitly. This seems to be rather annoying, and we have questions like this one: - https://community.jboss.org/thread/243346 I see no reasons to not enable it by default, following the same activation rules of other Hibernate dependencies: it's very conservative about not auto-enabling itself when not needed. May I open such a feature request? Happy to try the patching myself. Sanne From smarlow at redhat.com Fri Aug 1 09:29:38 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 01 Aug 2014 09:29:38 -0400 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: References: Message-ID: <53DB9642.80106@redhat.com> On 08/01/2014 06:58 AM, Sanne Grinovero wrote: > Currently users wishing for Search super-powers in their Hibernate > applications need to enable the module explicitly. > > This seems to be rather annoying, and we have questions like this one: > - https://community.jboss.org/thread/243346 I responded to this particular question, which was how to enable a module to be available from all deployments. That really has nothing to do with Hibernate Search. > > I see no reasons to not enable it by default, following the same > activation rules of other Hibernate dependencies: it's very > conservative about not auto-enabling itself when not needed. Are you asking if its possible to have Hibernate Search deployment code that detects use of Hibernate Search (perhaps after noticing use of some Hibernate Search annotation) and adds a deployment dependency on some Hibernate search module as a result? > > May I open such a feature request? Happy to try the patching myself. Not sure. I wonder if it would be better to have a separate Hibernate Search profile for WildFly that includes deployment code to automatically add application dependencies on Hibernate Search. For this to work, I think that Infinispan's dependency on Hibernate Search would need to not cause clustering/2lc failures when the Hibernate Search module profile is not installed. I think this would be nice as it would lay the groundwork for Search to be separate (depending on how you feel about that). :) > > Sanne > From brian.stansberry at redhat.com Fri Aug 1 09:34:55 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 01 Aug 2014 08:34:55 -0500 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: References: Message-ID: <53DB977F.90708@redhat.com> On 8/1/14, 5:58 AM, Sanne Grinovero wrote: > Currently users wishing for Search super-powers in their Hibernate > applications need to enable the module explicitly. > > This seems to be rather annoying, and we have questions like this one: > - https://community.jboss.org/thread/243346 > > I see no reasons to not enable it by default, following the same > activation rules of other Hibernate dependencies: it's very > conservative about not auto-enabling itself when not needed. > > May I open such a feature request? Happy to try the patching myself. > Would there be some configuration mechanism for users to turn this off? -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Fri Aug 1 14:49:51 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 1 Aug 2014 20:49:51 +0200 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: References: Message-ID: This sounds like a perfect valid case for new subsystem that would handle hibernate-search related stuff. and could based on some deployment markers enable / add dependent modules to deployment. it could also help configure search / ogm via server config :) On Fri, Aug 1, 2014 at 12:58 PM, Sanne Grinovero wrote: > Currently users wishing for Search super-powers in their Hibernate > applications need to enable the module explicitly. > > This seems to be rather annoying, and we have questions like this one: > - https://community.jboss.org/thread/243346 > > I see no reasons to not enable it by default, following the same > activation rules of other Hibernate dependencies: it's very > conservative about not auto-enabling itself when not needed. > > May I open such a feature request? Happy to try the patching myself. > > Sanne > _______________________________________________ > 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/20140801/b240fc42/attachment.html From sanne at hibernate.org Fri Aug 1 18:49:43 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 1 Aug 2014 23:49:43 +0100 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: <53DB977F.90708@redhat.com> References: <53DB977F.90708@redhat.com> Message-ID: On 1 August 2014 14:34, Brian Stansberry wrote: > On 8/1/14, 5:58 AM, Sanne Grinovero wrote: >> Currently users wishing for Search super-powers in their Hibernate >> applications need to enable the module explicitly. >> >> This seems to be rather annoying, and we have questions like this one: >> - https://community.jboss.org/thread/243346 >> >> I see no reasons to not enable it by default, following the same >> activation rules of other Hibernate dependencies: it's very >> conservative about not auto-enabling itself when not needed. >> >> May I open such a feature request? Happy to try the patching myself. >> > > Would there be some configuration mechanism for users to turn this off? Yes, just set "hibernate.search.autoregister_listeners" to "false". This property is read as any other Hibernate / JPA configuration properties, so could be set globally at boot of the JVM or in the scope of a specific Hibernate instance. But that's just an extreme emergency button, as it won't trigger if entities are not marked with Search specific annotations. -- Sanne > > > -- > 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 sanne at hibernate.org Fri Aug 1 19:08:15 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 2 Aug 2014 00:08:15 +0100 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: References: Message-ID: On 1 August 2014 19:49, Toma? Cerar wrote: > This sounds like a perfect valid case for new subsystem > that would handle hibernate-search related stuff. > > and could based on some deployment markers enable / add dependent modules to > deployment. > > it could also help configure search / ogm via server config :) Excellent idea :) But I'd prefer to do that in a second step if that's ok: I was hoping now to make only this minimal usability improvement for WildFly 8.2, and reserve those more significant improvements for WildFly 9. -- Sanne > > > On Fri, Aug 1, 2014 at 12:58 PM, Sanne Grinovero > wrote: >> >> Currently users wishing for Search super-powers in their Hibernate >> applications need to enable the module explicitly. >> >> This seems to be rather annoying, and we have questions like this one: >> - https://community.jboss.org/thread/243346 >> >> I see no reasons to not enable it by default, following the same >> activation rules of other Hibernate dependencies: it's very >> conservative about not auto-enabling itself when not needed. >> >> May I open such a feature request? Happy to try the patching myself. >> >> Sanne >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From sanne at hibernate.org Fri Aug 1 19:42:16 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 2 Aug 2014 00:42:16 +0100 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: <53DB9642.80106@redhat.com> References: <53DB9642.80106@redhat.com> Message-ID: On 1 August 2014 14:29, Scott Marlow wrote: > On 08/01/2014 06:58 AM, Sanne Grinovero wrote: >> >> Currently users wishing for Search super-powers in their Hibernate >> applications need to enable the module explicitly. >> >> This seems to be rather annoying, and we have questions like this one: >> - https://community.jboss.org/thread/243346 > > > I responded to this particular question, which was how to enable a module to > be available from all deployments. That really has nothing to do with > Hibernate Search. Thanks! But still that post is yet-another sign as I commonly see on Hibernate forums of people struggling to enable it: people migrating from other systems are used to see Search automatically enable itself without need of further hassle. Also people tend to not perceive it as an independent thing from the main Hibernate ORM, so when it doesn't work the modules system is the last thing they think to check. >> I see no reasons to not enable it by default, following the same >> activation rules of other Hibernate dependencies: it's very >> conservative about not auto-enabling itself when not needed. > > > Are you asking if its possible to have Hibernate Search deployment code that > detects use of Hibernate Search (perhaps after noticing use of some > Hibernate Search annotation) and adds a deployment dependency on some > Hibernate search module as a result? For user experience it shouldn't be different than Hibernate Envers. Implementation wise it's probably going to be slightly different, for example we have an independent versioning from ORM. I have no strong opinion on how we should do it, a simple solution would be to merge it with Hibernate ORM, like you did for Envers: it's a single jar, and having slot "main" the version mismatch doesn't matter. Alternatively the JPA deployer could add it to the user classpath like it does with the one for Hibernate ORM, but keeping the modules separate. I see detection as a nice to have: since it's functionally redundant with the detection performed by the code in Hibernate, we can tackle that at a second time. >> >> May I open such a feature request? Happy to try the patching myself. > > > Not sure. I wonder if it would be better to have a separate Hibernate > Search profile for WildFly that includes deployment code to automatically > add application dependencies on Hibernate Search. A profile for a single jar? We only need the one in the (existing) module "org.hibernate.search.orm": very similar to Envers, it was simply a mistake to not expose it by default from the beginning. > > For this to work, I think that Infinispan's dependency on Hibernate Search > would need to not cause clustering/2lc failures when the Hibernate Search > module profile is not installed. True, but that has been taken care of ;-) it's already nicely split in different JBoss Modules, and Infinispan depends on a different module "org.hibernate.search.engine", shared among the various projects depending on the engine. > > I think this would be nice as it would lay the groundwork for Search to be > separate (depending on how you feel about that). :) I agree, but it's a different aspect to get the dependency modularity right, and making sure the users don't get confused. I think the modules are correct already, now I'd like to make it easy to use. Sanne From jmesnil at redhat.com Mon Aug 4 09:51:01 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Mon, 4 Aug 2014 15:51:01 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> Message-ID: <9259A756-7671-47CD-A804-4A2B44C02DFE@redhat.com> On 07 Jul 2014, at 16:46, Jeff Mesnil wrote: > # Add Notification support to WildFly Management > > Tracked by https://issues.jboss.org/browse/WFLY-266 > > Part 1: Notification Definition > Part 2: Emitting a notification > Part 4: Notification Handlers => The 3 parts were done in WFLY-266[1] > Part 3: Global Resource Notifications => done in WFLY-3603[2] > Part 5: Domain Notifications => code to emit notifications in domain mode is trivial[3] but I can?t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC). So far, we have in master branch all we wanted to put in 8.2 and I?ll backport it. > Part 6: Integration with local JMX For this part, we only want to enable local JMX notifications. This would allow to use JMX notifications from WildFly through access of its MBeanServerService only. * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server) * Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine) * Using remote connection via our remoting-jmx connector does *not* work We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX. As it stands now, the integration in JMX is quite limited as only subsystems can access them. Another thing I?m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward. * when a resource is added/removed, the notification is emitted at at is location in the resource trees => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead * when an attribute changes, the type of the JMX notification remains attribute-value-written => Does it make sense to convert that to JMX AttributeChangeNotification? * A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that. I?m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration. Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not ?leak? notifications to the outside with critical information until we have proper RBAC support for it. Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time. wdyt? jeff [1] http://issues.jboss.org//browse/WFLY-266 [2] https://issues.jboss.org/browse/WFCORE-28 [3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jason.greene at redhat.com Mon Aug 4 10:27:02 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 4 Aug 2014 09:27:02 -0500 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <2D5957F6-277B-4E4F-B3B3-D00E56D44CC3@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <53BC5DA4.6000801@redhat.com> <2D5957F6-277B-4E4F-B3B3-D00E56D44CC3@redhat.com> Message-ID: On Jul 10, 2014, at 4:52 AM, Jeff Mesnil wrote: > > On 8 Jul 2014, at 23:07, Brian Stansberry wrote: > >> On 7/7/14, 9:46 AM, Jeff Mesnil wrote: -snip- >>> The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. >> >> Agreed. I don't think this should be an issue. We shouldn't use the >> Resource tree anyway as the data structure for retaining the registered >> handlers; a separate structure is needed. The wildcards are fine as long >> as there's a relevant ManagementResourceRegistration. > > In my POC, I am using a single Map to retain the handler and is separate from the resource tree. > The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses). > When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification. > I.e. the data structure grows with the number of handlers, not with the resources that emits notifications. Is this map broken up into path segments to mitigate the o(n) cost? e.g.determining if /x=blah/y=foo/z=bar matches x=blah/y=foo/* = 2 O(1) map lookups -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From kabir.khan at jboss.com Mon Aug 4 10:40:58 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 4 Aug 2014 15:40:58 +0100 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <9259A756-7671-47CD-A804-4A2B44C02DFE@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <9259A756-7671-47CD-A804-4A2B44C02DFE@redhat.com> Message-ID: <14126228-4B3D-48EC-A462-B79480892CB6@jboss.com> On 4 Aug 2014, at 14:51, Jeff Mesnil wrote: > > On 07 Jul 2014, at 16:46, Jeff Mesnil wrote: > >> # Add Notification support to WildFly Management >> >> Tracked by https://issues.jboss.org/browse/WFLY-266 >> >> Part 1: Notification Definition >> Part 2: Emitting a notification >> Part 4: Notification Handlers > > => The 3 parts were done in WFLY-266[1] > >> Part 3: Global Resource Notifications > > => done in WFLY-3603[2] > >> Part 5: Domain Notifications > > => code to emit notifications in domain mode is trivial[3] but I can?t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC). > > So far, we have in master branch all we wanted to put in 8.2 and I?ll backport it. > >> Part 6: Integration with local JMX > > For this part, we only want to enable local JMX notifications. > This would allow to use JMX notifications from WildFly through access of its MBeanServerService only. > > * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server) If that is true, that is a bug - we put some hooks into JBoss Modules ages ago to make the pluggable mbean server the platform mbean server. Are you seeing this in wildfly-core or wildfly? > * Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine) > * Using remote connection via our remoting-jmx connector does *not* work > > We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX. > > As it stands now, the integration in JMX is quite limited as only subsystems can access them. > > Another thing I?m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward. > * when a resource is added/removed, the notification is emitted at at is location in the resource trees > => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate > => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead > * when an attribute changes, the type of the JMX notification remains attribute-value-written > => Does it make sense to convert that to JMX AttributeChangeNotification? > * A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that. > > I?m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration. > Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not ?leak? notifications to the outside with critical information until we have proper RBAC support for it. > > Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time. > > wdyt? > jeff > > [1] http://issues.jboss.org//browse/WFLY-266 > [2] https://issues.jboss.org/browse/WFCORE-28 > [3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jmesnil at redhat.com Mon Aug 4 10:50:27 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Mon, 4 Aug 2014 16:50:27 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <14126228-4B3D-48EC-A462-B79480892CB6@jboss.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <9259A756-7671-47CD-A804-4A2B44C02DFE@redhat.com> <14126228-4B3D-48EC-A462-B79480892CB6@jboss.com> Message-ID: <2785C78A-32C5-413D-83DA-82C17017CD11@redhat.com> On 04 Aug 2014, at 16:40, Kabir Khan wrote: >>> Part 6: Integration with local JMX >> >> For this part, we only want to enable local JMX notifications. >> This would allow to use JMX notifications from WildFly through access of its MBeanServerService only. >> >> * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server) > If that is true, that is a bug - we put some hooks into JBoss Modules ages ago to make the pluggable mbean server the platform mbean server. Are you seeing this in wildfly-core or wildfly? You?re correct: the ManagementFactory.getPlatformMBeanServer() is our pluggable mbean server (I?ve been tricked by the tests that does not make the MBeanServerBuilder thingie). So our notifications can be used by JMX client through the ManagementFactory.getPlatformMBeanServer() too. -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Mon Aug 4 15:36:16 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 04 Aug 2014 14:36:16 -0500 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <9259A756-7671-47CD-A804-4A2B44C02DFE@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <9259A756-7671-47CD-A804-4A2B44C02DFE@redhat.com> Message-ID: <53DFE0B0.7010405@redhat.com> On 8/4/14, 8:51 AM, Jeff Mesnil wrote: > > On 07 Jul 2014, at 16:46, Jeff Mesnil wrote: > >> # Add Notification support to WildFly Management >> >> Tracked by https://issues.jboss.org/browse/WFLY-266 >> >> Part 1: Notification Definition >> Part 2: Emitting a notification >> Part 4: Notification Handlers > > => The 3 parts were done in WFLY-266[1] > >> Part 3: Global Resource Notifications > > => done in WFLY-3603[2] > >> Part 5: Domain Notifications > > => code to emit notifications in domain mode is trivial[3] but I can?t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC). > > So far, we have in master branch all we wanted to put in 8.2 and I?ll backport it. > >> Part 6: Integration with local JMX > > For this part, we only want to enable local JMX notifications. > This would allow to use JMX notifications from WildFly through access of its MBeanServerService only. > > * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server) > * Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine) > * Using remote connection via our remoting-jmx connector does *not* work > > We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX. > > As it stands now, the integration in JMX is quite limited as only subsystems can access them. > > Another thing I?m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward. > * when a resource is added/removed, the notification is emitted at at is location in the resource trees > => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate > => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead Are you saying the standard MBeanServerNotification via JMImplementation:type=MBeanServerDelegate wouldn't work? I think it should. > * when an attribute changes, the type of the JMX notification remains attribute-value-written > => Does it make sense to convert that to JMX AttributeChangeNotification? That seems like the intuitive thing to do, and anyone trying to use JMX to monitor the system would expect such notifications. Why wouldn't we do that? > * A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that. > > I?m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration. > Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not ?leak? notifications to the outside with critical information until we have proper RBAC support for it. > > Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time. > How complex would the RBAC support be? I'm reluctant to try for something in any way complex at this stage. > wdyt? > jeff > > [1] http://issues.jboss.org//browse/WFLY-266 > [2] https://issues.jboss.org/browse/WFCORE-28 > [3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From golovnin at gmx.net Mon Aug 4 15:43:32 2014 From: golovnin at gmx.net (Andrej Golovnin) Date: Mon, 4 Aug 2014 21:43:32 +0200 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: References: Message-ID: <42030287-3101-4E7E-B4BF-7CB61C7554C9@gmx.net> Hi Sanne, > I see no reasons to not enable it by default, following the same > activation rules of other Hibernate dependencies: it's very > conservative about not auto-enabling itself when not needed. > It is OK as long as it will be still possible to bundle Hibernate Search within an application and Hibernate would use the bundled version of Hibernate Search. Not all users want to use Hibernate and Hibernate Search, which are delivered with WildFly. For Hibernate we have a perfect solution developed by Scott, which allows WildFly to use Hibernate packaged inside of an application. At this place a big thanks to Scott for this wonderful solution! It works great! The same should be possible with Hibernate Search. Best regards, Andrej Golovnin From anmiller at redhat.com Mon Aug 4 18:59:48 2014 From: anmiller at redhat.com (Andrig Miller) Date: Mon, 4 Aug 2014 18:59:48 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53CD5040.5070409@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> Message-ID: <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> Considering our benchmarking work through our performance team we have actually discovered that we actually need pooling of Stateless Session beans, because of memory allocation rates being too high. Allocating objects is fast in the latest JVM's, that's for sure, but you can easily create a situation where the memory allocation rate becomes too high, and you start getting excessive GC overhead. With that in mind, we have recently created (John O'Hara did the work from the middle-ware performance team), a new implementation of the StrictMaxPool. That implementation uses a ConcurrentLinkedQueue as the underlying data structure, as the original used a simple LinkedList with synchronization, so essentially all accesses to the pool were serialized. So, this didn't scale. The new implementation is upstream in Wildfly 9. There is no configuration change necessary, as it replaces the old implementation and is compatible. Like everything, there are tradeoffs, and the mantra that has spread recently that pooling is bad, is simply not the case. In some cases, allocating an object everytime is the best approach, in others cases pooling will be the best approach. Fortunately, you can do either in Wildfly (and EAP). Like always, you have to test your specific application, in the properly configured environment to know for sure. Andy ----- Original Message ----- > From: "Wolf-Dieter Fink" > To: "Ralph Soika" , > wildfly-dev at lists.jboss.org > Sent: Monday, July 21, 2014 11:39:12 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > Hi Ralph, > as I said in your community thread ( > https://community.jboss.org/thread/242999 ) it is not only the > problem to add a pool for it. > At the moment there is only the strict-max-pool which limit the total > number of beans pooled - and also the total number of beans which > can be used in parallel. > So that means adding the pool is a performance issue, which can make > the situation better or worse depend on the application. > So you need to adjust it depend on your needs. > If there is another implementation of a pool, i.e. which allow to > have x pooled instances and more if needed, the pool might be back > as default. > For the moment it is makes no difference or is faster (in most cases) > without pooling. > - Wolf > On 21/07/14 18:16, Ralph Soika wrote: > > Hi, > > > I want to discuss the topic of Session Bean Pooling in WildFly. I > > know that there was a discussion in the past to disable pooling of > > EJB Session Beans per default in WildFly. > > > I understand when you argue that pooling a session bean is not > > faster > > than creating the bean from scratch each time a method is called. > > From the perspective of a application server developer this is a > > clear and easy decision. But from the view of an application > > developer this breaks one of the main concepts of session beans - > > the pooling. > > > As a application developer I suppose my bean is pooled and I can > > use > > one of the life-cycle annotations to control my bean. This is a > > basic concept for all kind of beans. First I thought it could be a > > compromise to pool only these beans which have a life-cycle > > annotation. But this isn't a solution. > > > Knowing that my bean will be pooled allows me - as a component > > developer - to use this as a caching mechanism. For example time > > intensive routines can also cache results in a local variable to be > > used next time a method is called. This isn't a bad practice and > > can > > increase performance of my component depending on the pool > > settings. > > > So my suggestion is to pool also stateless session ejbs in the > > future. I guess form the specification there is no duty to pool > > beans. So there is nothing wrong when not pooling beans. And again > > I > > don't want to criticize. But at the end not pooling will decrease > > the performance of WildFly. Not the container itself but the > > applications running in WildFly. > > > It takes me a long time to figure out why my application was a > > little > > bit slower in WildFly than in GlassFish until I recognized the > > missing pooling. I can activate pooling and everything is cool. But > > I guess some other application developers will only see that there > > application is slower in WildFly than on other application servers. > > > And this will effect their decision. That is the argument to > > activate > > the pool per default. > > > best regards > > > Ralph > > _______________________________________________ > 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/20140804/679001c4/attachment.html From david.lloyd at redhat.com Mon Aug 4 19:53:28 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 04 Aug 2014 18:53:28 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> Message-ID: <53E01CF8.4040703@redhat.com> Yeah I think we don't necessarily want the takeaway here to be that pooling is, in general, bad. It's just that our implementations needed (and still need) some more thought. I believe there are still a few stones yet unturned in this area. On 08/04/2014 05:59 PM, Andrig Miller wrote: > Considering our benchmarking work through our performance team we have > actually discovered that we actually need pooling of Stateless Session > beans, because of memory allocation rates being too high. > > Allocating objects is fast in the latest JVM's, that's for sure, but you > can easily create a situation where the memory allocation rate becomes > too high, and you start getting excessive GC overhead. > > With that in mind, we have recently created (John O'Hara did the work > from the middle-ware performance team), a new implementation of the > StrictMaxPool. That implementation uses a ConcurrentLinkedQueue as the > underlying data structure, as the original used a simple LinkedList with > synchronization, so essentially all accesses to the pool were > serialized. So, this didn't scale. The new implementation is upstream > in Wildfly 9. There is no configuration change necessary, as it > replaces the old implementation and is compatible. > > Like everything, there are tradeoffs, and the mantra that has spread > recently that pooling is bad, is simply not the case. In some cases, > allocating an object everytime is the best approach, in others cases > pooling will be the best approach. > > Fortunately, you can do either in Wildfly (and EAP). Like always, you > have to test your specific application, in the properly configured > environment to know for sure. > > Andy > > ------------------------------------------------------------------------ > > *From: *"Wolf-Dieter Fink" > *To: *"Ralph Soika" , wildfly-dev at lists.jboss.org > *Sent: *Monday, July 21, 2014 11:39:12 AM > *Subject: *Re: [wildfly-dev] Pooling EJB Session Beans per default > > Hi Ralph, > > as I said in your community thread > (https://community.jboss.org/thread/242999) it is not only the > problem to add a pool for it. > At the moment there is only the strict-max-pool which limit the > total number of beans pooled - and also the total number of beans > which can be used in parallel. > So that means adding the pool is a performance issue, which can make > the situation better or worse depend on the application. > So you need to adjust it depend on your needs. > > If there is another implementation of a pool, i.e. which allow to > have x pooled instances and more if needed, the pool might be back > as default. > For the moment it is makes no difference or is faster (in most > cases) without pooling. > > - Wolf > > On 21/07/14 18:16, Ralph Soika wrote: > > Hi, > > I want to discuss the topic of Session Bean Pooling in WildFly. > I know that there was a discussion in the past to disable > pooling of EJB Session Beans per default in WildFly. > I understand when you argue that pooling a session bean is not > faster than creating the bean from scratch each time a method is > called. From the perspective of a application server developer > this is a clear and easy decision. But from the view of an > application developer this breaks one of the main concepts of > session beans - the pooling. > As a application developer I suppose my bean is pooled and I can > use one of the life-cycle annotations to control my bean. This > is a basic concept for all kind of beans. First I thought it > could be a compromise to pool only these beans which have a > life-cycle annotation. But this isn't a solution. > Knowing that my bean will be pooled allows me - as a component > developer - to use this as a caching mechanism. For example time > intensive routines can also cache results in a local variable to > be used next time a method is called. This isn't a bad practice > and can increase performance of my component depending on the > pool settings. > > So my suggestion is to pool also stateless session ejbs in the > future. I guess form the specification there is no duty to pool > beans. So there is nothing wrong when not pooling beans. And > again I don't want to criticize. But at the end not pooling will > decrease the performance of WildFly. Not the container itself > but the applications running in WildFly. > It takes me a long time to figure out why my application was a > little bit slower in WildFly than in GlassFish until I > recognized the missing pooling. I can activate pooling and > everything is cool. But I guess some other application > developers will only see that there application is slower in > WildFly than on other application servers. > And this will effect their decision. That is the argument to > activate the pool per default. > > best regards > Ralph > > > > _______________________________________________ > 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 > -- - DML From bburke at redhat.com Mon Aug 4 20:22:16 2014 From: bburke at redhat.com (Bill Burke) Date: Mon, 04 Aug 2014 20:22:16 -0400 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> Message-ID: <53E023B8.1020508@redhat.com> I always liked the ThreadLocal pool. No synchronization, little to no allocations. On 8/4/2014 6:59 PM, Andrig Miller wrote: > Considering our benchmarking work through our performance team we have > actually discovered that we actually need pooling of Stateless Session > beans, because of memory allocation rates being too high. > > Allocating objects is fast in the latest JVM's, that's for sure, but you > can easily create a situation where the memory allocation rate becomes > too high, and you start getting excessive GC overhead. > > With that in mind, we have recently created (John O'Hara did the work > from the middle-ware performance team), a new implementation of the > StrictMaxPool. That implementation uses a ConcurrentLinkedQueue as the > underlying data structure, as the original used a simple LinkedList with > synchronization, so essentially all accesses to the pool were > serialized. So, this didn't scale. The new implementation is upstream > in Wildfly 9. There is no configuration change necessary, as it > replaces the old implementation and is compatible. > > Like everything, there are tradeoffs, and the mantra that has spread > recently that pooling is bad, is simply not the case. In some cases, > allocating an object everytime is the best approach, in others cases > pooling will be the best approach. > > Fortunately, you can do either in Wildfly (and EAP). Like always, you > have to test your specific application, in the properly configured > environment to know for sure. > > Andy > > ------------------------------------------------------------------------ > > *From: *"Wolf-Dieter Fink" > *To: *"Ralph Soika" , wildfly-dev at lists.jboss.org > *Sent: *Monday, July 21, 2014 11:39:12 AM > *Subject: *Re: [wildfly-dev] Pooling EJB Session Beans per default > > Hi Ralph, > > as I said in your community thread > (https://community.jboss.org/thread/242999) it is not only the > problem to add a pool for it. > At the moment there is only the strict-max-pool which limit the > total number of beans pooled - and also the total number of beans > which can be used in parallel. > So that means adding the pool is a performance issue, which can make > the situation better or worse depend on the application. > So you need to adjust it depend on your needs. > > If there is another implementation of a pool, i.e. which allow to > have x pooled instances and more if needed, the pool might be back > as default. > For the moment it is makes no difference or is faster (in most > cases) without pooling. > > - Wolf > > On 21/07/14 18:16, Ralph Soika wrote: > > Hi, > > I want to discuss the topic of Session Bean Pooling in WildFly. > I know that there was a discussion in the past to disable > pooling of EJB Session Beans per default in WildFly. > I understand when you argue that pooling a session bean is not > faster than creating the bean from scratch each time a method is > called. From the perspective of a application server developer > this is a clear and easy decision. But from the view of an > application developer this breaks one of the main concepts of > session beans - the pooling. > As a application developer I suppose my bean is pooled and I can > use one of the life-cycle annotations to control my bean. This > is a basic concept for all kind of beans. First I thought it > could be a compromise to pool only these beans which have a > life-cycle annotation. But this isn't a solution. > Knowing that my bean will be pooled allows me - as a component > developer - to use this as a caching mechanism. For example time > intensive routines can also cache results in a local variable to > be used next time a method is called. This isn't a bad practice > and can increase performance of my component depending on the > pool settings. > > So my suggestion is to pool also stateless session ejbs in the > future. I guess form the specification there is no duty to pool > beans. So there is nothing wrong when not pooling beans. And > again I don't want to criticize. But at the end not pooling will > decrease the performance of WildFly. Not the container itself > but the applications running in WildFly. > It takes me a long time to figure out why my application was a > little bit slower in WildFly than in GlassFish until I > recognized the missing pooling. I can activate pooling and > everything is cool. But I guess some other application > developers will only see that there application is slower in > WildFly than on other application servers. > And this will effect their decision. That is the argument to > activate the pool per default. > > best regards > Ralph > > > > _______________________________________________ > 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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jlivings at redhat.com Mon Aug 4 20:44:52 2014 From: jlivings at redhat.com (James Livingston) Date: Tue, 05 Aug 2014 10:44:52 +1000 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E023B8.1020508@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> Message-ID: <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: > I always liked the ThreadLocal pool. No synchronization, little to no > allocations. It also can cause massive memory leaks if invoked from threads which aren't re-used, like timer threads, and precautions aren't taken. AS/EAP 5 suffered from that problem with the default ThreadLocalPool. The major problem I've seen in support cases related to StrictMaxPool is the very arbitrary default size. I believe it used to be 30, and almost no-one knew that they might need to tune it to fit their applications' usage patterns and workload. Having a rising wait-time metric for the pool indicates that it may be too small, but I believe the statistics are disabled by default for performance reasons. InfinitePool obviously doesn't have that problem, but it would have been nicer if it had an idle period with expiry, like the JCA pools. -- James "Doc" Livingston JBoss Support Engineering Group From stuart.w.douglas at gmail.com Mon Aug 4 21:51:15 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 05 Aug 2014 11:51:15 +1000 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> Message-ID: <53E03893.9020609@gmail.com> I have often thought that a possible solution would be an unbounded pool that always keeps n instances around, but just creates new instances instead of blocking if the pool is exhausted. In the majority of cases new instance creation will be way more performant than blocking. Stuart James Livingston wrote: > On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: >> I always liked the ThreadLocal pool. No synchronization, little to no >> allocations. > > It also can cause massive memory leaks if invoked from threads which > aren't re-used, like timer threads, and precautions aren't taken. AS/EAP > 5 suffered from that problem with the default ThreadLocalPool. > > The major problem I've seen in support cases related to StrictMaxPool is > the very arbitrary default size. I believe it used to be 30, and almost > no-one knew that they might need to tune it to fit their applications' > usage patterns and workload. Having a rising wait-time metric for the > pool indicates that it may be too small, but I believe the statistics > are disabled by default for performance reasons. > > > InfinitePool obviously doesn't have that problem, but it would have been > nicer if it had an idle period with expiry, like the JCA pools. > From hbraun at redhat.com Tue Aug 5 03:42:11 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 5 Aug 2014 09:42:11 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources Message-ID: TL;DR: A proposal for improving parts of the management API that deal with static resource definitions Background: For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. Problem: Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: /subsystem=datasources/data-source=ExampleDS In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: /subsystem=ejb3/service=[async | remote | timer-service] In this case each resource under /subsystem=ejb3/service has a different type and only a single instance can exist: /service=async /service=remote /service=timer-service Lacking a better alternative, I coined the term 'squatter' resources, because these resources squat a specific address slots. Squatter resources can be pre-registered or non-exisiting when the management layer is started. In order to provide a data binding layer for the management console, we need to access the definition of a resource (:read-resource-description). With squatter resources this is basically impossible, because the existence of these types is hidden in the general API. I.e. sticking to the previous example, when querying the resource definition for the ejb3 subsystem, it pretends only single type 'service' exists, although it's actually three different 'service' types ./subsystem=ejb3:read-children-types { "outcome" => "success", "result" => [ [...], "service", [...] ] } Proposal: After a chat with Brian yesterday, we are proposing a new request parameter to the :read-children-types operations, that augments the result to reveal the existence of squatter resources: ./subsystem=ejb3:read-children-types(include-squatters=true) { "outcome" => "success", "result" => [ [...], "service=async", "service=remote", "service=timer-service" [...] ] } This works in a backwards compatible way and allows us to identify squatter resources and get to their resource definition. Thoughts and comments welcome. If you can think of better term than 'squatter' resources, please let me know as well. Regards, Heiko From hrupp at redhat.com Tue Aug 5 06:59:08 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 5 Aug 2014 12:59:08 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: Am 05.08.2014 um 09:42 schrieb Heiko Braun : > TL;DR: A proposal for improving parts of the management API that deal with static resource definitions I totally like this. Even if the RHQ approach is a bit different, the change will allow us to better support those potentially non-existing squatters. Do the squatters have all the same attributes or does one still individually deal with them? Heiko From hbraun at redhat.com Tue Aug 5 07:02:29 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 5 Aug 2014 13:02:29 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: Not sure I understand the question. Can you elaborate on this? On 05 Aug 2014, at 12:59, Heiko W.Rupp wrote: > Do the squatters have all the same attributes or does one still individually deal with them? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140805/7ea18dee/attachment.html From tomaz.cerar at gmail.com Tue Aug 5 07:43:15 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 5 Aug 2014 13:43:15 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: Hi, when I first started reading I was bit alarmed you want to do something crazy thing :-) Given that you just want to add extra option to read-children-types operation i see no harm in that. I would just name them differently, in all our terminology this types are just non wildcard resources if you look at the PathElement which is essentially what you are talking about. in case that you have path element key = * you have wildcard address/resource which you use as normal for cases were you have key=value you have static non wildcard address/resource. so i would rather use some term in this vicinity. -- tomaz On Tue, Aug 5, 2014 at 9:42 AM, Heiko Braun wrote: > > > TL;DR: A proposal for improving parts of the management API that deal > with static resource definitions > > > Background: > > For future Wildfly versions we plan to re-architect the management console > to make better use the existing meta data. The goal is to provide a data > binding layer that automates much of the retrieval and update of the > configuration and runtime data. To achieve this goal, we need to remove > some of the roadblocks that prevent further automation. This is the first > of a series of posts that explains some of the challenges we facing and a > proposal to improve the situation. > > > Problem: > > Typically we deal with resources that addressable through a key value > pair, where the key of the tuple depicts the type of the resource and the > value the name or identify of a specific resource instance, i.e.: > > /subsystem=datasources/data-source=ExampleDS > > In this case 'ExampleDS' is the name of a resource of type 'data-source'. > The type is associated with a specific resource definition, that's > typically retrieved through the :read-resource-description operation. In > the following sections I am going to refer to these resource as 'regular' > resources. > > In some situations, it seems more feasible (and valid) to construct a > model representation without instance names, i.e.: > > /subsystem=ejb3/service=[async | remote | timer-service] > > In this case each resource under /subsystem=ejb3/service has a different > type and only a single instance can exist: > > /service=async > /service=remote > /service=timer-service > > Lacking a better alternative, I coined the term 'squatter' resources, > because these resources squat a specific address slots. Squatter resources > can be pre-registered or non-exisiting when the management layer is started. > > In order to provide a data binding layer for the management console, we > need to access the definition of a resource (:read-resource-description). > With squatter resources this is basically impossible, because the existence > of these types is hidden in the general API. I.e. sticking to the previous > example, when querying the resource definition for the ejb3 subsystem, it > pretends only single type 'service' exists, although it's actually three > different 'service' types > > ./subsystem=ejb3:read-children-types > { > "outcome" => "success", > "result" => [ > [...], > "service", > [...] > ] > } > > Proposal: > > After a chat with Brian yesterday, we are proposing a new request > parameter to the :read-children-types operations, that augments the result > to reveal the existence of squatter resources: > > ./subsystem=ejb3:read-children-types(include-squatters=true) > { > "outcome" => "success", > "result" => [ > [...], > "service=async", > "service=remote", > "service=timer-service" > [...] > ] > } > > This works in a backwards compatible way and allows us to identify > squatter resources and get to their resource definition. > > > Thoughts and comments welcome. > If you can think of better term than 'squatter' resources, please let me > know as well. > > Regards, Heiko > _______________________________________________ > 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/20140805/110c4a57/attachment.html From kabir.khan at jboss.com Tue Aug 5 07:45:01 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 5 Aug 2014 12:45:01 +0100 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: I have used ?specific? vs ?wildcard? in the past when explaining/discussing stuff On 5 Aug 2014, at 12:43, Toma? Cerar wrote: > Hi, > > when I first started reading I was bit alarmed you want to do something crazy thing :-) > > Given that you just want to add extra option to read-children-types operation i see no harm in that. > I would just name them differently, in all our terminology this types are just non wildcard resources > if you look at the PathElement which is essentially what you are talking about. > in case that you have path element key = * you have wildcard address/resource which you use as normal > for cases were you have key=value you have static non wildcard address/resource. > > so i would rather use some term in this vicinity. > > -- > tomaz > > > > On Tue, Aug 5, 2014 at 9:42 AM, Heiko Braun wrote: > > > TL;DR: A proposal for improving parts of the management API that deal with static resource definitions > > > Background: > > For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. > > > Problem: > > Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: > > /subsystem=datasources/data-source=ExampleDS > > In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. > > In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: > > /subsystem=ejb3/service=[async | remote | timer-service] > > In this case each resource under /subsystem=ejb3/service has a different type and only a single instance can exist: > > /service=async > /service=remote > /service=timer-service > > Lacking a better alternative, I coined the term 'squatter' resources, because these resources squat a specific address slots. Squatter resources can be pre-registered or non-exisiting when the management layer is started. > > In order to provide a data binding layer for the management console, we need to access the definition of a resource (:read-resource-description). With squatter resources this is basically impossible, because the existence of these types is hidden in the general API. I.e. sticking to the previous example, when querying the resource definition for the ejb3 subsystem, it pretends only single type 'service' exists, although it's actually three different 'service' types > > ./subsystem=ejb3:read-children-types > { > "outcome" => "success", > "result" => [ > [...], > "service", > [...] > ] > } > > Proposal: > > After a chat with Brian yesterday, we are proposing a new request parameter to the :read-children-types operations, that augments the result to reveal the existence of squatter resources: > > ./subsystem=ejb3:read-children-types(include-squatters=true) > { > "outcome" => "success", > "result" => [ > [...], > "service=async", > "service=remote", > "service=timer-service" > [...] > ] > } > > This works in a backwards compatible way and allows us to identify squatter resources and get to their resource definition. > > > Thoughts and comments welcome. > If you can think of better term than 'squatter' resources, please let me know as well. > > Regards, Heiko > _______________________________________________ > 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 hrupp at redhat.com Tue Aug 5 09:03:35 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 5 Aug 2014 15:03:35 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: Am 05.08.2014 um 13:02 schrieb Heiko Braun : > Not sure I understand the question. Can you elaborate on this? Will have service=async and service=timer-service have the same attributes / operations (as the type - the part left of the '=' - is the same)? I guess not, but would like to know anyway. > > On 05 Aug 2014, at 12:59, Heiko W.Rupp wrote: > >> Do the squatters have all the same attributes or does one still individually deal with them? > -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht M?nchen HRB 153243 Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters From hrupp at redhat.com Tue Aug 5 09:04:40 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 5 Aug 2014 15:04:40 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> Am 05.08.2014 um 13:45 schrieb Kabir Khan : > I have used ?specific? vs ?wildcard? in the past when explaining/discussing stuff Aren't the "specific" ones also "singletons"; I think that would also capture the spirit. Heiko From anmiller at redhat.com Tue Aug 5 09:07:13 2014 From: anmiller at redhat.com (Andrig Miller) Date: Tue, 5 Aug 2014 09:07:13 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E03893.9020609@gmail.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E03893.9020609@gmail.com> Message-ID: <19564951.3735.1407244029843.JavaMail.andrig@worklaptop.miller.org> Your idea is something that I like as well. You have a min, but no max, and no blocking for an instance if there isn't one immediately available. The downside is its unbounded (I have also had customers tell me they needed a strict max option because they were delivering an application to their customers, and wanted to have strict control of the resources used), but it would be a nice compliment to what we have now. On the old InfinitePool, using ThreadLocal, it was actually faster than the old StrictMaxPool, and it actually wasn't unbounded, because it would be bound by the thread pool size of the calling thread to the EJB instance. While it was faster than the old StrictMaxPool, it was probably because of the serialized nature of the old implementation. There is definitely room for additional implementations here. Andy ----- Original Message ----- > From: "Stuart Douglas" > To: "James Livingston" > Cc: wildfly-dev at lists.jboss.org > Sent: Monday, August 4, 2014 7:51:15 PM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > I have often thought that a possible solution would be an unbounded > pool > that always keeps n instances around, but just creates new instances > instead of blocking if the pool is exhausted. In the majority of > cases > new instance creation will be way more performant than blocking. > > Stuart > > James Livingston wrote: > > On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: > >> I always liked the ThreadLocal pool. No synchronization, little > >> to no > >> allocations. > > > > It also can cause massive memory leaks if invoked from threads > > which > > aren't re-used, like timer threads, and precautions aren't taken. > > AS/EAP > > 5 suffered from that problem with the default ThreadLocalPool. > > > > The major problem I've seen in support cases related to > > StrictMaxPool is > > the very arbitrary default size. I believe it used to be 30, and > > almost > > no-one knew that they might need to tune it to fit their > > applications' > > usage patterns and workload. Having a rising wait-time metric for > > the > > pool indicates that it may be too small, but I believe the > > statistics > > are disabled by default for performance reasons. > > > > > > InfinitePool obviously doesn't have that problem, but it would have > > been > > nicer if it had an idle period with expiry, like the JCA pools. > > > _______________________________________________ > 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 Aug 5 09:17:06 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 05 Aug 2014 14:17:06 +0100 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <19564951.3735.1407244029843.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E03893.9020609@gmail.com> <19564951.3735.1407244029843.JavaMail.andrig@worklaptop.miller.org> Message-ID: <53E0D952.40700@jboss.com> On 05/08/14 14:07, Andrig Miller wrote: > Your idea is something that I like as well. You have a min, but no max, and no blocking for an instance if there isn't one immediately available. The downside is its unbounded (I have also had customers tell me they needed a strict max option because they were delivering an application to their customers, and wanted to have strict control of the resources used), but it would be a nice compliment to what we have now. Probably a decision that will vary depending on the deployment but if we can limit the number of threads processing requests then having a second limit on the pool could be argued as being redundant for many cases. > On the old InfinitePool, using ThreadLocal, it was actually faster than the old StrictMaxPool, and it actually wasn't unbounded, because it would be bound by the thread pool size of the calling thread to the EJB instance. While it was faster than the old StrictMaxPool, it was probably because of the serialized nature of the old implementation. > > There is definitely room for additional implementations here. > > Andy > > ----- Original Message ----- >> From: "Stuart Douglas" >> To: "James Livingston" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Monday, August 4, 2014 7:51:15 PM >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >> >> I have often thought that a possible solution would be an unbounded >> pool >> that always keeps n instances around, but just creates new instances >> instead of blocking if the pool is exhausted. In the majority of >> cases >> new instance creation will be way more performant than blocking. >> >> Stuart >> >> James Livingston wrote: >>> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: >>>> I always liked the ThreadLocal pool. No synchronization, little >>>> to no >>>> allocations. >>> >>> It also can cause massive memory leaks if invoked from threads >>> which >>> aren't re-used, like timer threads, and precautions aren't taken. >>> AS/EAP >>> 5 suffered from that problem with the default ThreadLocalPool. >>> >>> The major problem I've seen in support cases related to >>> StrictMaxPool is >>> the very arbitrary default size. I believe it used to be 30, and >>> almost >>> no-one knew that they might need to tune it to fit their >>> applications' >>> usage patterns and workload. Having a rising wait-time metric for >>> the >>> pool indicates that it may be too small, but I believe the >>> statistics >>> are disabled by default for performance reasons. >>> >>> >>> InfinitePool obviously doesn't have that problem, but it would have >>> been >>> nicer if it had an idle period with expiry, like the JCA pools. >>> >> _______________________________________________ >> 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 bburke at redhat.com Tue Aug 5 09:32:04 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 Aug 2014 09:32:04 -0400 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> Message-ID: <53E0DCD4.8000406@redhat.com> On 8/4/2014 8:44 PM, James Livingston wrote: > On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: >> I always liked the ThreadLocal pool. No synchronization, little to no >> allocations. > > It also can cause massive memory leaks if invoked from threads which > aren't re-used, like timer threads, and precautions aren't taken. AS/EAP > 5 suffered from that problem with the default ThreadLocalPool. > Which is also something that could be mitigated by a common thread facility. Something AS/EAP 5 didn't have. Honestly though, I think this talk of EJB pooling is ridiculous. Component layers like CDI and JAX-RS don't have pooled architectures for their per-request objects. Also, in an average application, there are multiple orders of magnitude more non component classes that are being instantiated per request. Just think of all the Strings created by a simple HTTP request. You want a better focus? How about JSON/XML marshalling? Which could make things much easier to maintain then the hand-coded parsers that Wildfly uses to parse config. And much faster and less memory at runtime for SOAP and JAX-RS request that currently rely on java reflection. You could go research perfect hashing algorithms for URL matching with servlets and JAX-RS. You could go do some perf analysis of all of our frameworks to make memory reduction and speed recommendations or even Pull Requests. You could visit each major project and make sure our automated builds have and can run automated stress tests and are measured against previous versions. Or you could just focus on these silly benchmarks that test no-op HTTP and EJB requests. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jai.forums2013 at gmail.com Tue Aug 5 09:38:45 2014 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 05 Aug 2014 19:08:45 +0530 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E0DCD4.8000406@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> Message-ID: <53E0DE65.6050309@gmail.com> I think it's important to remember that the application developers use the @PostConstruct and @PreDestroy on stateless EJBs for initialization and destroying certain application specific resources. In a non-pooled case this is going to affect the performance and as has been noted, it's ultimately something that each application needs to review. So this isn't exactly the same as per-request objects, as far as I see it and isn't just a case of Java object instantiation. -Jaikiran On Tuesday 05 August 2014 07:02 PM, Bill Burke wrote: > > On 8/4/2014 8:44 PM, James Livingston wrote: >> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: >>> I always liked the ThreadLocal pool. No synchronization, little to no >>> allocations. >> It also can cause massive memory leaks if invoked from threads which >> aren't re-used, like timer threads, and precautions aren't taken. AS/EAP >> 5 suffered from that problem with the default ThreadLocalPool. >> > Which is also something that could be mitigated by a common thread > facility. Something AS/EAP 5 didn't have. > > Honestly though, I think this talk of EJB pooling is ridiculous. > Component layers like CDI and JAX-RS don't have pooled architectures for > their per-request objects. Also, in an average application, there are > multiple orders of magnitude more non component classes that are being > instantiated per request. Just think of all the Strings created by a > simple HTTP request. > > You want a better focus? How about JSON/XML marshalling? Which could > make things much easier to maintain then the hand-coded parsers that > Wildfly uses to parse config. And much faster and less memory at > runtime for SOAP and JAX-RS request that currently rely on java reflection. > > You could go research perfect hashing algorithms for URL matching with > servlets and JAX-RS. > > You could go do some perf analysis of all of our frameworks to make > memory reduction and speed recommendations or even Pull Requests. > > You could visit each major project and make sure our automated builds > have and can run automated stress tests and are measured against > previous versions. > > Or you could just focus on these silly benchmarks that test no-op HTTP > and EJB requests. > > From david.lloyd at redhat.com Tue Aug 5 09:40:35 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 05 Aug 2014 08:40:35 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <19564951.3735.1407244029843.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E03893.9020609@gmail.com> <19564951.3735.1407244029843.JavaMail.andrig@worklaptop.miller.org> Message-ID: <53E0DED3.9010205@redhat.com> I have always contended that the most appropriate place for throttling server usage is at the front end. If the number of incoming web and EJB requests can be limited, then everything else probably should just be unbounded (else you enter a configuration nightmare because *everything* has knobs). This way you can limit configuration to total incoming requests, and specific resources that have to be limited (like DB connections), and be assured of reasonable performance instead of having to read the encyclopedia to figure out all the tuning parameters you have to futz with. On 08/05/2014 08:07 AM, Andrig Miller wrote: > Your idea is something that I like as well. You have a min, but no max, and no blocking for an instance if there isn't one immediately available. The downside is its unbounded (I have also had customers tell me they needed a strict max option because they were delivering an application to their customers, and wanted to have strict control of the resources used), but it would be a nice compliment to what we have now. > > On the old InfinitePool, using ThreadLocal, it was actually faster than the old StrictMaxPool, and it actually wasn't unbounded, because it would be bound by the thread pool size of the calling thread to the EJB instance. While it was faster than the old StrictMaxPool, it was probably because of the serialized nature of the old implementation. > > There is definitely room for additional implementations here. > > Andy > > ----- Original Message ----- >> From: "Stuart Douglas" >> To: "James Livingston" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Monday, August 4, 2014 7:51:15 PM >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >> >> I have often thought that a possible solution would be an unbounded >> pool >> that always keeps n instances around, but just creates new instances >> instead of blocking if the pool is exhausted. In the majority of >> cases >> new instance creation will be way more performant than blocking. >> >> Stuart >> >> James Livingston wrote: >>> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: >>>> I always liked the ThreadLocal pool. No synchronization, little >>>> to no >>>> allocations. >>> >>> It also can cause massive memory leaks if invoked from threads >>> which >>> aren't re-used, like timer threads, and precautions aren't taken. >>> AS/EAP >>> 5 suffered from that problem with the default ThreadLocalPool. >>> >>> The major problem I've seen in support cases related to >>> StrictMaxPool is >>> the very arbitrary default size. I believe it used to be 30, and >>> almost >>> no-one knew that they might need to tune it to fit their >>> applications' >>> usage patterns and workload. Having a rising wait-time metric for >>> the >>> pool indicates that it may be too small, but I believe the >>> statistics >>> are disabled by default for performance reasons. >>> >>> >>> InfinitePool obviously doesn't have that problem, but it would have >>> been >>> nicer if it had an idle period with expiry, like the JCA pools. >>> >> _______________________________________________ >> 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 > -- - DML From anmiller at redhat.com Tue Aug 5 09:43:07 2014 From: anmiller at redhat.com (Andrig Miller) Date: Tue, 5 Aug 2014 09:43:07 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E0DCD4.8000406@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> Message-ID: <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Bill Burke" > To: "James Livingston" > Cc: wildfly-dev at lists.jboss.org > Sent: Tuesday, August 5, 2014 7:32:04 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > > On 8/4/2014 8:44 PM, James Livingston wrote: > > On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: > >> I always liked the ThreadLocal pool. No synchronization, little > >> to no > >> allocations. > > > > It also can cause massive memory leaks if invoked from threads > > which > > aren't re-used, like timer threads, and precautions aren't taken. > > AS/EAP > > 5 suffered from that problem with the default ThreadLocalPool. > > > > Which is also something that could be mitigated by a common thread > facility. Something AS/EAP 5 didn't have. > > Honestly though, I think this talk of EJB pooling is ridiculous. > Component layers like CDI and JAX-RS don't have pooled architectures > for > their per-request objects. Also, in an average application, there > are > multiple orders of magnitude more non component classes that are > being > instantiated per request. Just think of all the Strings created by a > simple HTTP request. > > You want a better focus? How about JSON/XML marshalling? Which > could > make things much easier to maintain then the hand-coded parsers that > Wildfly uses to parse config. And much faster and less memory at > runtime for SOAP and JAX-RS request that currently rely on java > reflection. > > You could go research perfect hashing algorithms for URL matching > with > servlets and JAX-RS. > > You could go do some perf analysis of all of our frameworks to make > memory reduction and speed recommendations or even Pull Requests. > > You could visit each major project and make sure our automated builds > have and can run automated stress tests and are measured against > previous versions. > > Or you could just focus on these silly benchmarks that test no-op > HTTP > and EJB requests. > Those silly benchmarks, are indeed silly. Any workload that doesn't actually do anything with the requests is not very helpful. You can be really fast on them, and be really slow on a workload that actually does something. We have already seen this in one case recently. I also don't like most of the "performance test suites/benchmarks" we have developed internally. They all suffer from some of the same issues. They don't model real application interactions and they also tend to have data sizes that are static (like 1KB payloads, or in some cases not within middle-ware, payloads that are as small as 8 bytes!). Developing benchmarks is not a trivial exercise. Andy > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From anmiller at redhat.com Tue Aug 5 09:44:47 2014 From: anmiller at redhat.com (Andrig Miller) Date: Tue, 5 Aug 2014 09:44:47 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E0DED3.9010205@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E03893.9020609@gmail.com> <19564951.3735.1407244029843.JavaMail.andrig@worklaptop.miller.org> <53E0DED3.9010205@redhat.com> Message-ID: <16499158.3811.1407246285749.JavaMail.andrig@worklaptop.miller.org> I tend to agree with you. It does get very complicated very quickly with all the resource related configuration. The more complex the workload, the more complex the configuration becomes. Andy ----- Original Message ----- > From: "David M. Lloyd" > To: wildfly-dev at lists.jboss.org > Sent: Tuesday, August 5, 2014 7:40:35 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > I have always contended that the most appropriate place for > throttling > server usage is at the front end. If the number of incoming web and > EJB > requests can be limited, then everything else probably should just be > unbounded (else you enter a configuration nightmare because > *everything* > has knobs). This way you can limit configuration to total incoming > requests, and specific resources that have to be limited (like DB > connections), and be assured of reasonable performance instead of > having > to read the encyclopedia to figure out all the tuning parameters you > have to futz with. > > On 08/05/2014 08:07 AM, Andrig Miller wrote: > > Your idea is something that I like as well. You have a min, but no > > max, and no blocking for an instance if there isn't one > > immediately available. The downside is its unbounded (I have also > > had customers tell me they needed a strict max option because they > > were delivering an application to their customers, and wanted to > > have strict control of the resources used), but it would be a nice > > compliment to what we have now. > > > > On the old InfinitePool, using ThreadLocal, it was actually faster > > than the old StrictMaxPool, and it actually wasn't unbounded, > > because it would be bound by the thread pool size of the calling > > thread to the EJB instance. While it was faster than the old > > StrictMaxPool, it was probably because of the serialized nature of > > the old implementation. > > > > There is definitely room for additional implementations here. > > > > Andy > > > > ----- Original Message ----- > >> From: "Stuart Douglas" > >> To: "James Livingston" > >> Cc: wildfly-dev at lists.jboss.org > >> Sent: Monday, August 4, 2014 7:51:15 PM > >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > >> > >> I have often thought that a possible solution would be an > >> unbounded > >> pool > >> that always keeps n instances around, but just creates new > >> instances > >> instead of blocking if the pool is exhausted. In the majority of > >> cases > >> new instance creation will be way more performant than blocking. > >> > >> Stuart > >> > >> James Livingston wrote: > >>> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: > >>>> I always liked the ThreadLocal pool. No synchronization, > >>>> little > >>>> to no > >>>> allocations. > >>> > >>> It also can cause massive memory leaks if invoked from threads > >>> which > >>> aren't re-used, like timer threads, and precautions aren't taken. > >>> AS/EAP > >>> 5 suffered from that problem with the default ThreadLocalPool. > >>> > >>> The major problem I've seen in support cases related to > >>> StrictMaxPool is > >>> the very arbitrary default size. I believe it used to be 30, and > >>> almost > >>> no-one knew that they might need to tune it to fit their > >>> applications' > >>> usage patterns and workload. Having a rising wait-time metric for > >>> the > >>> pool indicates that it may be too small, but I believe the > >>> statistics > >>> are disabled by default for performance reasons. > >>> > >>> > >>> InfinitePool obviously doesn't have that problem, but it would > >>> have > >>> been > >>> nicer if it had an idle period with expiry, like the JCA pools. > >>> > >> _______________________________________________ > >> 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 > > > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Tue Aug 5 09:49:39 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 05 Aug 2014 08:49:39 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: <53E0E0F3.80605@redhat.com> On 08/05/2014 02:42 AM, Heiko Braun wrote: > TL;DR: A proposal for improving parts of the management API that deal with static resource definitions > > Background: > > For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. > > Problem: > > Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: > > /subsystem=datasources/data-source=ExampleDS > > In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. > > In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: > > /subsystem=ejb3/service=[async | remote | timer-service] We've solved this a different way in the "next" management model. We introduce the concept of an "attribute group". In your example we'd perhaps have an attribute group for async, one for remote, and one for timer-service within the root resource. An attribute group is something like a composition resource. They can be optional or mandatory, and they can be named or anonymous. A named attribute group would be separately addressable as a unit, or can be accessed using a qualifier syntax e.g. "thegroup.theattribute". Also they can be arbitrarily nested. An anonymous attribute group is just a logical grouping which is only relevant to the server Java API itself and is invisible to the so-called "DMR" or REST style API. We can use these groups to retrofit existing subsystems without breaking compatibility (this gives certain code reuse benefits which are not important to this discussion). This way we preserve the invariant that all attributes with a given key have a related type (we also introduce the concept of type hierarchies though, which mitigates this constraint in a different way, but that's not related to this). -- - DML From sanne at hibernate.org Tue Aug 5 09:49:51 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 5 Aug 2014 14:49:51 +0100 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: <42030287-3101-4E7E-B4BF-7CB61C7554C9@gmx.net> References: <42030287-3101-4E7E-B4BF-7CB61C7554C9@gmx.net> Message-ID: Hi Andrej, that's an excellent point. I also don't want to make it harder for users to play with the latest versions we'll be releasing - normally at a higher pace than WildFly. I guess I'll need learn more about writing a subsystem to make sure these options are covered. Thanks all, Sanne On 4 August 2014 20:43, Andrej Golovnin wrote: > Hi Sanne, > >> I see no reasons to not enable it by default, following the same >> activation rules of other Hibernate dependencies: it's very >> conservative about not auto-enabling itself when not needed. >> > > It is OK as long as it will be still possible to bundle Hibernate Search > within an application and Hibernate would use the bundled version of > Hibernate Search. > > Not all users want to use Hibernate and Hibernate Search, > which are delivered with WildFly. > > For Hibernate we have a perfect solution developed by Scott, which > allows WildFly to use Hibernate packaged inside of an application. > At this place a big thanks to Scott for this wonderful solution! It works great! > The same should be possible with Hibernate Search. > > Best regards, > Andrej Golovnin From brian.stansberry at redhat.com Tue Aug 5 09:50:16 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 08:50:16 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: <53E0E118.10206@redhat.com> On 8/5/14, 8:03 AM, Heiko W.Rupp wrote: > > Am 05.08.2014 um 13:02 schrieb Heiko Braun : > >> Not sure I understand the question. Can you elaborate on this? > > Will have service=async and service=timer-service > have the same attributes / operations (as the type - the part left of the '=' - is the same)? > I guess not, but would like to know anyway. > They are quite different. The issue here is how to identify "types". All address segments consist of key/value pairs[1], and in most cases the key identifies the type and the value is a specific instance name. There are many cases though where a pair isn't really needed to identify the type, and there can only be one instance. (Your 'singleton' idea for the term to use is definitely a good candidate.) But we have to force the address element into a pair. In some cases we have really crappy pairs that just repeat the key, foo=FOO. Where we could we tried to come up with some sort of common concept to use as a key, just to make it more intuitive for people tab completing in the CLI. That's where this 'service' key comes from. But "common concept" != an actual type. [1] Why key/value pairs? First, in many cases it's the right fit. But also, requiring this allows us always to map resource addresses to JMX ObjectNames. >> >> On 05 Aug 2014, at 12:59, Heiko W.Rupp wrote: >> >>> Do the squatters have all the same attributes or does one still individually deal with them? >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Aug 5 10:00:50 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 09:00:50 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <53E0E0F3.80605@redhat.com> References: <53E0E0F3.80605@redhat.com> Message-ID: <53E0E392.2040804@redhat.com> On 8/5/14, 8:49 AM, David M. Lloyd wrote: > On 08/05/2014 02:42 AM, Heiko Braun wrote: >> TL;DR: A proposal for improving parts of the management API that deal with static resource definitions >> >> Background: >> >> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. >> >> Problem: >> >> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: >> >> /subsystem=datasources/data-source=ExampleDS >> >> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. >> >> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: >> >> /subsystem=ejb3/service=[async | remote | timer-service] > > We've solved this a different way in the "next" management model. We > introduce the concept of an "attribute group". In your example we'd > perhaps have an attribute group for async, one for remote, and one for > timer-service within the root resource. > > An attribute group is something like a composition resource. They can > be optional or mandatory, and they can be named or anonymous. > > A named attribute group would be separately addressable as a unit, or > can be accessed using a qualifier syntax e.g. "thegroup.theattribute". > Also they can be arbitrarily nested. > > An anonymous attribute group is just a logical grouping which is only > relevant to the server Java API itself and is invisible to the so-called > "DMR" or REST style API. We can use these groups to retrofit existing > subsystems without breaking compatibility (this gives certain code reuse > benefits which are not important to this discussion). > > This way we preserve the invariant that all attributes with a given key > have a related type (we also introduce the concept of type hierarchies > though, which mitigates this constraint in a different way, but that's > not related to this). > Is there a notion of null/undefined for the attribute group itself, as opposed to the individual attributes? That's a conceptual distinction -- a resource doesn't exist unless it's added. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Tue Aug 5 10:12:18 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 5 Aug 2014 16:12:18 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: <0D607553-EF11-4C48-8C8A-C3C67F947583@redhat.com> > Am 05.08.2014 um 15:03 schrieb "Heiko W.Rupp" : > > >> Am 05.08.2014 um 13:02 schrieb Heiko Braun : >> >> Not sure I understand the question. Can you elaborate on this? > > Will have service=async and service=timer-service > have the same attributes / operations (as the type - the part left of the '=' - is the same)? > I guess not, but would like to know anyway As i said, these are different resource types and thus have different operations and attributes. >> >>> On 05 Aug 2014, at 12:59, Heiko W.Rupp wrote: >>> >>> Do the squatters have all the same attributes or does one still individually deal with them? > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht M?nchen HRB 153243 > Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters > From hbraun at redhat.com Tue Aug 5 10:15:04 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 5 Aug 2014 16:15:04 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <53E0E0F3.80605@redhat.com> References: <53E0E0F3.80605@redhat.com> Message-ID: <9FB2E518-FE02-401C-A46D-505A4EF2A331@redhat.com> But i guess attribute groups dont represent resource types. I.e they dont have operations associated, like types do. I think your example demonstrates a different concept. > Am 05.08.2014 um 15:49 schrieb "David M. Lloyd" : > >> On 08/05/2014 02:42 AM, Heiko Braun wrote: >> TL;DR: A proposal for improving parts of the management API that deal with static resource definitions >> >> Background: >> >> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. >> >> Problem: >> >> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: >> >> /subsystem=datasources/data-source=ExampleDS >> >> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. >> >> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: >> >> /subsystem=ejb3/service=[async | remote | timer-service] > > We've solved this a different way in the "next" management model. We > introduce the concept of an "attribute group". In your example we'd > perhaps have an attribute group for async, one for remote, and one for > timer-service within the root resource. > > An attribute group is something like a composition resource. They can > be optional or mandatory, and they can be named or anonymous. > > A named attribute group would be separately addressable as a unit, or > can be accessed using a qualifier syntax e.g. "thegroup.theattribute". > Also they can be arbitrarily nested. > > An anonymous attribute group is just a logical grouping which is only > relevant to the server Java API itself and is invisible to the so-called > "DMR" or REST style API. We can use these groups to retrofit existing > subsystems without breaking compatibility (this gives certain code reuse > benefits which are not important to this discussion). > > This way we preserve the invariant that all attributes with a given key > have a related type (we also introduce the concept of type hierarchies > though, which mitigates this constraint in a different way, but that's > not related to this). > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Tue Aug 5 10:15:47 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 5 Aug 2014 09:15:47 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> Message-ID: <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> On Aug 5, 2014, at 8:43 AM, Andrig Miller wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: "James Livingston" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Tuesday, August 5, 2014 7:32:04 AM >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >> >> >> >> On 8/4/2014 8:44 PM, James Livingston wrote: >>> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: >>>> I always liked the ThreadLocal pool. No synchronization, little >>>> to no >>>> allocations. >>> >>> It also can cause massive memory leaks if invoked from threads >>> which >>> aren't re-used, like timer threads, and precautions aren't taken. >>> AS/EAP >>> 5 suffered from that problem with the default ThreadLocalPool. >>> >> >> Which is also something that could be mitigated by a common thread >> facility. Something AS/EAP 5 didn't have. >> >> Honestly though, I think this talk of EJB pooling is ridiculous. >> Component layers like CDI and JAX-RS don't have pooled architectures >> for >> their per-request objects. Also, in an average application, there >> are >> multiple orders of magnitude more non component classes that are >> being >> instantiated per request. Just think of all the Strings created by a >> simple HTTP request. >> >> You want a better focus? How about JSON/XML marshalling? Which >> could >> make things much easier to maintain then the hand-coded parsers that >> Wildfly uses to parse config. And much faster and less memory at >> runtime for SOAP and JAX-RS request that currently rely on java >> reflection. >> >> You could go research perfect hashing algorithms for URL matching >> with >> servlets and JAX-RS. >> >> You could go do some perf analysis of all of our frameworks to make >> memory reduction and speed recommendations or even Pull Requests. >> >> You could visit each major project and make sure our automated builds >> have and can run automated stress tests and are measured against >> previous versions. >> >> Or you could just focus on these silly benchmarks that test no-op >> HTTP >> and EJB requests. >> > > Those silly benchmarks, are indeed silly. Any workload that doesn't actually do anything with the requests is not very helpful. You can be really fast on them, and be really slow on a workload that actually does something. We have already seen this in one case recently. It?s all about precision, and limiting variables. I know its fun to criticize micro benchmarks (obviously micro is indeed relative because a great deal of processing goes on even when you have EJB and HTTP requests that don?t do much), however micro benchmarks, provided they are measured correctly, are quick to run and make it easy to tell what you have to fix. Large gigantic apps on the other hand are difficult to analyze, and do not necessarily represent activity that a differently architected app would show. To use an example, if you have pattern matching code, and you want it to be fast, it?s much easier (and accurate) to benchmark the pattern matching code then it is to benchmaark a full EE app that happens to use pattern matching in a few places. Arguing against targeted benchmarks is like arguing that you should never write a test case, because only real production load will show problems?. To some extent thats true, but that doesn?t mean that the problems you catch in simulations won?t affect production users. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From david.lloyd at redhat.com Tue Aug 5 10:21:10 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 05 Aug 2014 09:21:10 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <53E0E392.2040804@redhat.com> References: <53E0E0F3.80605@redhat.com> <53E0E392.2040804@redhat.com> Message-ID: <53E0E856.10001@redhat.com> On 08/05/2014 09:00 AM, Brian Stansberry wrote: > On 8/5/14, 8:49 AM, David M. Lloyd wrote: >> On 08/05/2014 02:42 AM, Heiko Braun wrote: >>> TL;DR: A proposal for improving parts of the management API that deal with static resource definitions >>> >>> Background: >>> >>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. >>> >>> Problem: >>> >>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: >>> >>> /subsystem=datasources/data-source=ExampleDS >>> >>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. >>> >>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: >>> >>> /subsystem=ejb3/service=[async | remote | timer-service] >> >> We've solved this a different way in the "next" management model. We >> introduce the concept of an "attribute group". In your example we'd >> perhaps have an attribute group for async, one for remote, and one for >> timer-service within the root resource. >> >> An attribute group is something like a composition resource. They can >> be optional or mandatory, and they can be named or anonymous. >> >> A named attribute group would be separately addressable as a unit, or >> can be accessed using a qualifier syntax e.g. "thegroup.theattribute". >> Also they can be arbitrarily nested. >> >> An anonymous attribute group is just a logical grouping which is only >> relevant to the server Java API itself and is invisible to the so-called >> "DMR" or REST style API. We can use these groups to retrofit existing >> subsystems without breaking compatibility (this gives certain code reuse >> benefits which are not important to this discussion). >> >> This way we preserve the invariant that all attributes with a given key >> have a related type (we also introduce the concept of type hierarchies >> though, which mitigates this constraint in a different way, but that's >> not related to this). >> > > Is there a notion of null/undefined for the attribute group itself, as > opposed to the individual attributes? Yes, but only for "optional" attribute groups. IOW the resource author can decide if that's appropriate or not. I have not yet completely worked out how manipulation operations would look for this. I think it may be closely tied in to what we do for so-called "complex" attributes though. > That's a conceptual distinction -- a resource doesn't exist unless it's > added. Yes, it's a distinct concept. However (at least for the given example) I think that an attribute group is a better fit. The problem with "squatters" is that they don't really have a common API, and yet they aren't really independent - it's just a way of addressing the composition of a parent resource. You can't really use the mechanism (as described) to plug in extensions. So it's yet another logical model for resources we have to introduce. I think in terms of the logical model of management resources themselves, we're close to the breaking point in a couple ways, even if only due to the way we handle subsystems, inter-resource linkage etc., where it's going to be difficult to come up with any kind of internally consistent management API unification concept if we make it any more complex. The problem that Heiko is trying to solve, I think, is that there's a tension here. Large resources aren't, by themselves, inherently "bad", in terms of the system and its implementation. However once you introduce human interfaces like CLI and console, it becomes difficult for people to manage due to just the overall spamming of management information. So there's a tension between having complete and robust resources, and making them consumable by normal human beings. I definitely agree with this, and I think that trying to solve this is a very reasonable and logical step (and those who know me should know that "reasonable" is about the highest compliment that I give). But if we do solve this then it has to be done in a way that we can adapt to, or else we may cross the line from "the new management is a pretty big effort" to "the new management model is dead". And I think that if the new management model can't accommodate a new abstraction in a logically consistent way, then nothing else will be able to either. -- - DML From david.lloyd at redhat.com Tue Aug 5 10:25:04 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 05 Aug 2014 09:25:04 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <9FB2E518-FE02-401C-A46D-505A4EF2A331@redhat.com> References: <53E0E0F3.80605@redhat.com> <9FB2E518-FE02-401C-A46D-505A4EF2A331@redhat.com> Message-ID: <53E0E940.3010003@redhat.com> Well, you can't really use "resource types" as part of the definition (i.e. justification) of what a resource type is, else nothing will ever meet that definition. :-) But in any event, if it is important (and logical) to do so, I think we could easily extend operations to be "scoped" to an attribute group without really flexing the logical model very much. The entire point of attribute groups is pretty much exactly what your use case is. I don't want to marginalize your idea - it's a good idea - I just don't think I can accommodate it well in the new management model; if I did, it would end up being exactly like attribute groups anyway (but with distinct addresses). But then making them be required would be impossible. On 08/05/2014 09:15 AM, Heiko Braun wrote: > But i guess attribute groups dont represent resource types. I.e they dont have operations associated, like types do. > > I think your example demonstrates a different concept. >> Am 05.08.2014 um 15:49 schrieb "David M. Lloyd" : >> >>> On 08/05/2014 02:42 AM, Heiko Braun wrote: >>> TL;DR: A proposal for improving parts of the management API that deal with static resource definitions >>> >>> Background: >>> >>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. >>> >>> Problem: >>> >>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: >>> >>> /subsystem=datasources/data-source=ExampleDS >>> >>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. >>> >>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: >>> >>> /subsystem=ejb3/service=[async | remote | timer-service] >> >> We've solved this a different way in the "next" management model. We >> introduce the concept of an "attribute group". In your example we'd >> perhaps have an attribute group for async, one for remote, and one for >> timer-service within the root resource. >> >> An attribute group is something like a composition resource. They can >> be optional or mandatory, and they can be named or anonymous. >> >> A named attribute group would be separately addressable as a unit, or >> can be accessed using a qualifier syntax e.g. "thegroup.theattribute". >> Also they can be arbitrarily nested. >> >> An anonymous attribute group is just a logical grouping which is only >> relevant to the server Java API itself and is invisible to the so-called >> "DMR" or REST style API. We can use these groups to retrofit existing >> subsystems without breaking compatibility (this gives certain code reuse >> benefits which are not important to this discussion). >> >> This way we preserve the invariant that all attributes with a given key >> have a related type (we also introduce the concept of type hierarchies >> though, which mitigates this constraint in a different way, but that's >> not related to this). >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- - DML From hrupp at redhat.com Tue Aug 5 10:26:30 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 5 Aug 2014 16:26:30 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <53E0E0F3.80605@redhat.com> References: <53E0E0F3.80605@redhat.com> Message-ID: Am 05.08.2014 um 15:49 schrieb David M. Lloyd : > > A named attribute group would be separately addressable as a unit, or > can be accessed using a qualifier syntax e.g. "thegroup.theattribute". > Also they can be arbitrarily nested. The latter scares me, as its representation in UIs can become quite problematic. From tomaz.cerar at gmail.com Tue Aug 5 10:30:42 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 5 Aug 2014 16:30:42 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: <53E0E0F3.80605@redhat.com> Message-ID: On Tue, Aug 5, 2014 at 4:26 PM, Heiko W.Rupp wrote: > The latter scares me, as its representation in UIs can become quite > problematic. > How so? this is the easiest thing to represent in gui, just imagine it as
holder in html form... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140805/a4faab9b/attachment.html From bburke at redhat.com Tue Aug 5 10:32:15 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 Aug 2014 10:32:15 -0400 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> Message-ID: <53E0EAEF.1010703@redhat.com> On 8/5/2014 10:15 AM, Jason Greene wrote: >> Those silly benchmarks, are indeed silly. Any workload that doesn't actually do anything with the requests is not very helpful. You can be really fast on them, and be really slow on a workload that actually does something. We have already seen this in one case recently. > > It?s all about precision, and limiting variables. I know its fun to criticize micro benchmarks (obviously micro is indeed relative because a great deal of processing goes on even when you have EJB and HTTP requests that don?t do much), however micro benchmarks, provided they are measured correctly, are quick to run and make it easy to tell what you have to fix. Large gigantic apps on the other hand are difficult to analyze, and do not necessarily represent activity that a differently architected app would show. To use an example, if you have pattern matching code, and you want it to be fast, it?s much easier (and accurate) to benchmark the pattern matching code then it is to benchmaark a full EE app that happens to use pattern matching in a few places. > > Arguing against targeted benchmarks is like arguing that you should never write a test case, because only real production load will show problems?. To some extent thats true, but that doesn?t mean that the problems you catch in simulations won?t affect production users. > I'm more worried about focus rather than the actual benchmarks considering how resource strapped every project seems to be. I'd like to see a discussion started on what are the most important and *ripe* areas for optimization and then have the performance team validate and make recommendations on any priority list that this discussion generates. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From kabir.khan at jboss.com Tue Aug 5 10:20:58 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 5 Aug 2014 15:20:58 +0100 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> Message-ID: <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> On 5 Aug 2014, at 14:04, Heiko W.Rupp wrote: > > Am 05.08.2014 um 13:45 schrieb Kabir Khan : > >> I have used ?specific? vs ?wildcard? in the past when explaining/discussing stuff > > Aren't the "specific" ones also "singletons"; I think that would also capture the spirit. To me ?singleton? sounds the best so far > > Heiko > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Tue Aug 5 10:34:03 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 05 Aug 2014 09:34:03 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: <53E0E0F3.80605@redhat.com> Message-ID: <53E0EB5B.3010900@redhat.com> On 08/05/2014 09:26 AM, Heiko W.Rupp wrote: > > Am 05.08.2014 um 15:49 schrieb David M. Lloyd : >> >> A named attribute group would be separately addressable as a unit, or >> can be accessed using a qualifier syntax e.g. "thegroup.theattribute". >> Also they can be arbitrarily nested. > > The latter scares me, as its representation in UIs can become quite > problematic. Well look at it this way - it's already problematic ;-) As with all things, we will rely on good sense and moderation. One can also reason that the farther you nest, the less important the grouping becomes; after one or two levels of nesting, if such a resource ever even comes in to being, the UI hint could simply be "sort by group" and otherwise treat it as flat, which is no worse than the status quo today (and arguably slightly better). -- - DML From kabir.khan at jboss.com Tue Aug 5 10:23:20 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 5 Aug 2014 15:23:20 +0100 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: On 5 Aug 2014, at 14:03, Heiko W.Rupp wrote: > > Am 05.08.2014 um 13:02 schrieb Heiko Braun : > >> Not sure I understand the question. Can you elaborate on this? > > Will have service=async and service=timer-service > have the same attributes / operations (as the type - the part left of the '=' - is the same)? > I guess not, but would like to know anyway. Not necessarily If the resource registration is done against service=*, it will be the same. If there is a resource registration for service=async, and one for service=timer-service they can be different. > >> >> On 05 Aug 2014, at 12:59, Heiko W.Rupp wrote: >> >>> Do the squatters have all the same attributes or does one still individually deal with them? >> > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht M?nchen HRB 153243 > Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From bburke at redhat.com Tue Aug 5 10:39:13 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 Aug 2014 10:39:13 -0400 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E0EAEF.1010703@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> Message-ID: <53E0EC91.6020103@redhat.com> On 8/5/2014 10:32 AM, Bill Burke wrote: > > > On 8/5/2014 10:15 AM, Jason Greene wrote: >>> Those silly benchmarks, are indeed silly. Any workload that doesn't actually do anything with the requests is not very helpful. You can be really fast on them, and be really slow on a workload that actually does something. We have already seen this in one case recently. >> >> It?s all about precision, and limiting variables. I know its fun to criticize micro benchmarks (obviously micro is indeed relative because a great deal of processing goes on even when you have EJB and HTTP requests that don?t do much), however micro benchmarks, provided they are measured correctly, are quick to run and make it easy to tell what you have to fix. Large gigantic apps on the other hand are difficult to analyze, and do not necessarily represent activity that a differently architected app would show. To use an example, if you have pattern matching code, and you want it to be fast, it?s much easier (and accurate) to benchmark the pattern matching code then it is to benchmaark a full EE app that happens to use pattern matching in a few places. >> >> Arguing against targeted benchmarks is like arguing that you should never write a test case, because only real production load will show problems?. To some extent thats true, but that doesn?t mean that the problems you catch in simulations won?t affect production users. >> > > I'm more worried about focus rather than the actual benchmarks > considering how resource strapped every project seems to be. I'd like > to see a discussion started on what are the most important and *ripe* > areas for optimization and then have the performance team validate and > make recommendations on any priority list that this discussion generates. > Furthermore, if we put efforts into a particularly ripe area for optimization and there exists no popular benchmark to showcase these efforts, then create one, open source it, and promote it. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From brian.stansberry at redhat.com Tue Aug 5 10:46:59 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 09:46:59 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: Message-ID: <53E0EE63.8080605@redhat.com> On 8/5/14, 2:42 AM, Heiko Braun wrote: > > Proposal: > > After a chat with Brian yesterday, we are proposing a new request parameter to the :read-children-types operations, that augments the result to reveal the existence of squatter resources: > > ./subsystem=ejb3:read-children-types(include-squatters=true) > { > "outcome" => "success", > "result" => [ > [...], > "service=async", > "service=remote", > "service=timer-service" > [...] > ] > } > > This works in a backwards compatible way and allows us to identify squatter resources and get to their resource definition. > We also have form of subtyping that's something we should explore as we sort this. We allow a "squatter" resource description to override a non-squatter definition. When it does this it can add attributes or child types. The use case this was added for is where different implementations of the service underlying a resource are possible and we register the subtype when we install the service and learn what it supports. For example, start the server with the ExampleDS *disabled* and read the resource description tree for the datasources subsystem: [standalone at localhost:9990 subsystem=datasources] :read-resource-description(recursive=true) { .... "children" => { ... "data-source" => { "description" => "A JDBC data-source configuration", "model-description" => { "*" => {...} } } } } But once you enable the datasource, another child description is registered, for "ExampleDS": standalone at localhost:9990 subsystem=datasources] :read-resource-description(recursive=true) { .... "children" => { ... "data-source" => { "description" => "A JDBC data-source configuration", "model-description" => { "ExampleDS" => {...}, "*" => {...} } } } } The ExampleDS registration includes statistics attributes provided by the underlying datasource. So, how should we clarify this? Does :read-children-types(include-squatters=true) include "datasource=ExampleDS" in the result? How do we disambiguate this "subtype" case from the "singleton" case? I'll think about this a bit. One vague thought I have is the :read-resource-description output is a bit too terse if you don't add recursive=true. It's structure really assumes the non-squatter case: [standalone at localhost:9990 subsystem=datasources] :read-resource-description { "outcome" => "success", "result" => { "description" => "The data-sources subsystem, used to declare JDBC data-sources", "attributes" => {...}}, "operations" => undefined, "notifications" => undefined, "children" => { "jdbc-driver" => { "description" => "Service that make a JDBC driver available for use in the runtime", "model-description" => undefined }, "xa-data-source" => { "description" => "A JDBC XA data-source configuration", "model-description" => undefined }, "data-source" => { "description" => "A JDBC data-source configuration", "model-description" => undefined } } } } It might be ok to just expand that '"model-description" => undefined' part with a bit more data. It's a change in the output for an existing op, which could be a compatibility issue, but why would a client care about that? The existing '"model-description" => undefined' is just useless noise that a client wouldn't process anyway. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Tue Aug 5 10:51:11 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 5 Aug 2014 09:51:11 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E0EAEF.1010703@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> Message-ID: <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> On Aug 5, 2014, at 9:32 AM, Bill Burke wrote: > > > On 8/5/2014 10:15 AM, Jason Greene wrote: >>> Those silly benchmarks, are indeed silly. Any workload that doesn't actually do anything with the requests is not very helpful. You can be really fast on them, and be really slow on a workload that actually does something. We have already seen this in one case recently. >> >> It?s all about precision, and limiting variables. I know its fun to criticize micro benchmarks (obviously micro is indeed relative because a great deal of processing goes on even when you have EJB and HTTP requests that don?t do much), however micro benchmarks, provided they are measured correctly, are quick to run and make it easy to tell what you have to fix. Large gigantic apps on the other hand are difficult to analyze, and do not necessarily represent activity that a differently architected app would show. To use an example, if you have pattern matching code, and you want it to be fast, it?s much easier (and accurate) to benchmark the pattern matching code then it is to benchmaark a full EE app that happens to use pattern matching in a few places. >> >> Arguing against targeted benchmarks is like arguing that you should never write a test case, because only real production load will show problems?. To some extent thats true, but that doesn?t mean that the problems you catch in simulations won?t affect production users. >> > > I'm more worried about focus rather than the actual benchmarks considering how resource strapped every project seems to be. I'd like to see a discussion started on what are the most important and *ripe* areas for optimization and then have the performance team validate and make recommendations on any priority list that this discussion generates. The pooling concerns (aside from the occasional expensive post constructs) actually came from a large app/benchmark that the perf team was testing, and they were seeing an optimized strict max pool outperform no pooling at all, and it wasn?t post construct. Their theory is/was GC pressure, because this benchmark/app spends a lot of time in GC, and they see higher GC activity with no pooling. It?s possible it could be an indirect difference though, like the fact that strict max pool acts as a throttle might prevent the system from degrading as a result of no longer being able to keep up with the benchmark load. Another possibility to look into is that I see we do: interceptorContext.setContextData(new HashMap()); *AND* private Map instanceData = new HashMap(); Aside from the unnecessary overhead, since JDK7, HashMap construction uses the murmur algorithm which requires using a random number generation under global locking. There were plans to optimize this, but it might not be in JDK7 yet. In a few places we use alternative map implementations to work around the issue. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Tue Aug 5 11:05:46 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 5 Aug 2014 10:05:46 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> Message-ID: <4B60FBEF-B9F5-4FDD-AF35-FD258CD0E3D3@redhat.com> On Aug 5, 2014, at 9:51 AM, Jason Greene wrote: > > On Aug 5, 2014, at 9:32 AM, Bill Burke wrote: > >> >> >> On 8/5/2014 10:15 AM, Jason Greene wrote: >>>> Those silly benchmarks, are indeed silly. Any workload that doesn't actually do anything with the requests is not very helpful. You can be really fast on them, and be really slow on a workload that actually does something. We have already seen this in one case recently. >>> >>> It?s all about precision, and limiting variables. I know its fun to criticize micro benchmarks (obviously micro is indeed relative because a great deal of processing goes on even when you have EJB and HTTP requests that don?t do much), however micro benchmarks, provided they are measured correctly, are quick to run and make it easy to tell what you have to fix. Large gigantic apps on the other hand are difficult to analyze, and do not necessarily represent activity that a differently architected app would show. To use an example, if you have pattern matching code, and you want it to be fast, it?s much easier (and accurate) to benchmark the pattern matching code then it is to benchmaark a full EE app that happens to use pattern matching in a few places. >>> >>> Arguing against targeted benchmarks is like arguing that you should never write a test case, because only real production load will show problems?. To some extent thats true, but that doesn?t mean that the problems you catch in simulations won?t affect production users. >>> >> >> I'm more worried about focus rather than the actual benchmarks considering how resource strapped every project seems to be. I'd like to see a discussion started on what are the most important and *ripe* areas for optimization and then have the performance team validate and make recommendations on any priority list that this discussion generates. > > The pooling concerns (aside from the occasional expensive post constructs) actually came from a large app/benchmark that the perf team was testing, and they were seeing an optimized strict max pool outperform no pooling at all, and it wasn?t post construct. Their theory is/was GC pressure, because this benchmark/app spends a lot of time in GC, and they see higher GC activity with no pooling. It?s possible it could be an indirect difference though, like the fact that strict max pool acts as a throttle might prevent the system from degrading as a result of no longer being able to keep up with the benchmark load. > > Another possibility to look into is that I see we do: > interceptorContext.setContextData(new HashMap()); > > *AND* > > private Map instanceData = new HashMap(); > > > Aside from the unnecessary overhead, since JDK7, HashMap construction uses the murmur algorithm which requires using a random number generation under global locking. There were plans to optimize this, but it might not be in JDK7 yet. In a few places we use alternative map implementations to work around the issue. > Looks like a fix for this is actually in u40+, although we still should reduce those allocations. http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b03bbdef3a88 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Tue Aug 5 11:15:19 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 10:15:19 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <53E0E856.10001@redhat.com> References: <53E0E0F3.80605@redhat.com> <53E0E392.2040804@redhat.com> <53E0E856.10001@redhat.com> Message-ID: <53E0F507.40409@redhat.com> On 8/5/14, 9:21 AM, David M. Lloyd wrote: > On 08/05/2014 09:00 AM, Brian Stansberry wrote: >> On 8/5/14, 8:49 AM, David M. Lloyd wrote: >>> On 08/05/2014 02:42 AM, Heiko Braun wrote: >>>> TL;DR: A proposal for improving parts of the management API that deal with static resource definitions >>>> >>>> Background: >>>> >>>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. >>>> >>>> Problem: >>>> >>>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: >>>> >>>> /subsystem=datasources/data-source=ExampleDS >>>> >>>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. >>>> >>>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: >>>> >>>> /subsystem=ejb3/service=[async | remote | timer-service] >>> >>> We've solved this a different way in the "next" management model. We >>> introduce the concept of an "attribute group". In your example we'd >>> perhaps have an attribute group for async, one for remote, and one for >>> timer-service within the root resource. >>> >>> An attribute group is something like a composition resource. They can >>> be optional or mandatory, and they can be named or anonymous. >>> >>> A named attribute group would be separately addressable as a unit, or >>> can be accessed using a qualifier syntax e.g. "thegroup.theattribute". >>> Also they can be arbitrarily nested. >>> >>> An anonymous attribute group is just a logical grouping which is only >>> relevant to the server Java API itself and is invisible to the so-called >>> "DMR" or REST style API. We can use these groups to retrofit existing >>> subsystems without breaking compatibility (this gives certain code reuse >>> benefits which are not important to this discussion). >>> >>> This way we preserve the invariant that all attributes with a given key >>> have a related type (we also introduce the concept of type hierarchies >>> though, which mitigates this constraint in a different way, but that's >>> not related to this). >>> >> >> Is there a notion of null/undefined for the attribute group itself, as >> opposed to the individual attributes? > > Yes, but only for "optional" attribute groups. IOW the resource author > can decide if that's appropriate or not. > > I have not yet completely worked out how manipulation operations would > look for this. I think it may be closely tied in to what we do for > so-called "complex" attributes though. > >> That's a conceptual distinction -- a resource doesn't exist unless it's >> added. > > Yes, it's a distinct concept. However (at least for the given example) > I think that an attribute group is a better fit. The problem with > "squatters" is that they don't really have a common API, and yet they > aren't really independent - it's just a way of addressing the > composition of a parent resource. Where is the boundary for "independent"? I've concluded that over time we've gone too far toward making resources out of things that are not independent, with resources used for things that really aren't at all. But is service=remote not semi-independent? It adds an entire chunk of functionality, including a requirement for the presence of a remoting subsystem. I see how it could be treated as just another aspect of the parent. I'd like to have a clearly explainable boundary line. Maybe a bit fuzzy, but something clear for 98% of the cases. > You can't really use the mechanism > (as described) to plug in extensions. So it's yet another logical model > for resources we have to introduce. I think in terms of the logical > model of management resources themselves, we're close to the breaking > point in a couple ways, even if only due to the way we handle > subsystems, inter-resource linkage etc., where it's going to be > difficult to come up with any kind of internally consistent management > API unification concept if we make it any more complex. > > The problem that Heiko is trying to solve, I think, is that there's a > tension here. Large resources aren't, by themselves, inherently "bad", > in terms of the system and its implementation. However once you > introduce human interfaces like CLI and console, it becomes difficult > for people to manage due to just the overall spamming of management > information. So there's a tension between having complete and robust > resources, and making them consumable by normal human beings. I > definitely agree with this, and I think that trying to solve this is a > very reasonable and logical step (and those who know me should know that > "reasonable" is about the highest compliment that I give). > > But if we do solve this then it has to be done in a way that we can > adapt to, or else we may cross the line from "the new management is a > pretty big effort" to "the new management model is dead". And I think > that if the new management model can't accommodate a new abstraction in > a logically consistent way, then nothing else will be able to either. > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Tue Aug 5 11:19:15 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 5 Aug 2014 10:19:15 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> Message-ID: <3229B298-6D9B-47BF-92AB-7F637529B0FA@redhat.com> On Aug 4, 2014, at 7:44 PM, James Livingston wrote: > On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: >> I always liked the ThreadLocal pool. No synchronization, little to no >> allocations. > > It also can cause massive memory leaks if invoked from threads which > aren't re-used, like timer threads, and precautions aren't taken. AS/EAP > 5 suffered from that problem with the default ThreadLocalPool. Right this is the reason we didn?t preserve it, as it leads to both instance leaks and class loader leaks. However a thread local based pool with a controlled life-cycle attached to deployment is something we have always wanted to do, it?s just been lower priority.. > > The major problem I've seen in support cases related to StrictMaxPool is > the very arbitrary default size. I believe it used to be 30, and almost > no-one knew that they might need to tune it to fit their applications' > usage patterns and workload. Having a rising wait-time metric for the > pool indicates that it may be too small, but I believe the statistics > are disabled by default for performance reasons. Yes that was a bad default, although the big problem is that any value we pick is a bad default. Ideally you want an auto-tuned construct which is tied into our tuning with worker pools (e.g. like the thread local approach above). Absent that its better to just take the small hit of allocating a few temporary objects per request, and let the user setup the pool config that best fits their app. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Tue Aug 5 11:29:34 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 5 Aug 2014 10:29:34 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E03893.9020609@gmail.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E03893.9020609@gmail.com> Message-ID: I think a thread local solution would be superior. Like strict max, an unbounded pool has a lot of potential for misconfiguration. On Aug 4, 2014, at 8:51 PM, Stuart Douglas wrote: > I have often thought that a possible solution would be an unbounded pool > that always keeps n instances around, but just creates new instances > instead of blocking if the pool is exhausted. In the majority of cases > new instance creation will be way more performant than blocking. > > Stuart > > James Livingston wrote: >> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: >>> I always liked the ThreadLocal pool. No synchronization, little to no >>> allocations. >> >> It also can cause massive memory leaks if invoked from threads which >> aren't re-used, like timer threads, and precautions aren't taken. AS/EAP >> 5 suffered from that problem with the default ThreadLocalPool. >> >> The major problem I've seen in support cases related to StrictMaxPool is >> the very arbitrary default size. I believe it used to be 30, and almost >> no-one knew that they might need to tune it to fit their applications' >> usage patterns and workload. Having a rising wait-time metric for the >> pool indicates that it may be too small, but I believe the statistics >> are disabled by default for performance reasons. >> >> >> InfinitePool obviously doesn't have that problem, but it would have been >> nicer if it had an idle period with expiry, like the JCA pools. >> > _______________________________________________ > 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 bburke at redhat.com Tue Aug 5 11:49:29 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 Aug 2014 11:49:29 -0400 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> Message-ID: <53E0FD09.1000605@redhat.com> On 8/5/2014 10:51 AM, Jason Greene wrote: > > On Aug 5, 2014, at 9:32 AM, Bill Burke wrote: > >> >> >> On 8/5/2014 10:15 AM, Jason Greene wrote: >>>> Those silly benchmarks, are indeed silly. Any workload that doesn't actually do anything with the requests is not very helpful. You can be really fast on them, and be really slow on a workload that actually does something. We have already seen this in one case recently. >>> >>> It?s all about precision, and limiting variables. I know its fun to criticize micro benchmarks (obviously micro is indeed relative because a great deal of processing goes on even when you have EJB and HTTP requests that don?t do much), however micro benchmarks, provided they are measured correctly, are quick to run and make it easy to tell what you have to fix. Large gigantic apps on the other hand are difficult to analyze, and do not necessarily represent activity that a differently architected app would show. To use an example, if you have pattern matching code, and you want it to be fast, it?s much easier (and accurate) to benchmark the pattern matching code then it is to benchmaark a full EE app that happens to use pattern matching in a few places. >>> >>> Arguing against targeted benchmarks is like arguing that you should never write a test case, because only real production load will show problems?. To some extent thats true, but that doesn?t mean that the problems you catch in simulations won?t affect production users. >>> >> >> I'm more worried about focus rather than the actual benchmarks considering how resource strapped every project seems to be. I'd like to see a discussion started on what are the most important and *ripe* areas for optimization and then have the performance team validate and make recommendations on any priority list that this discussion generates. > > The pooling concerns (aside from the occasional expensive post constructs) actually came from a large app/benchmark that the perf team was testing, and they were seeing an optimized strict max pool outperform no pooling at all, and it wasn?t post construct. Their theory is/was GC pressure, because this benchmark/app spends a lot of time in GC, and they see higher GC activity with no pooling. It?s possible it could be an indirect difference though, like the fact that strict max pool acts as a throttle might prevent the system from degrading as a result of no longer being able to keep up with the benchmark load. > Its a horrible theory. :) How many EJB instances of a give type are created per request? Generally only 1. 1 instance of one object of one type! My $5 bet is that if you went into EJB code and started counting how many object allocations were made per request, you'd lose count very quickly. Better yet, run a single remote EJB request through a perf tool and let it count the number of allocations for you. It will be greater than 1. :) Maybe the StrictMaxPool has an effect on performance because it creates a global synchronization bottleneck. Throughput is less and you end up having less concurrent per-request objects being allocated and GC'd. > Another possibility to look into is that I see we do: > interceptorContext.setContextData(new HashMap()); > > *AND* > > private Map instanceData = new HashMap(); > > > Aside from the unnecessary overhead, since JDK7, HashMap construction uses the murmur algorithm which requires using a random number generation under global locking. There were plans to optimize this, but it might not be in JDK7 yet. In a few places we use alternative map implementations to work around the issue. > IMO, it is more likely that most projects haven't gone through the level of refactorings that performance-focused projects like Undertow have gone through. I'll put another $5 bet down that only the Wildfly family of projects under you and DML have gone through any real performance analysis and optimizations. Just think of all the crappiness that is happening in the security layer alone! Also, any optimizations projects have done are probably focused on speed and throughput which generally is at the expense of memory. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From david.lloyd at redhat.com Tue Aug 5 12:03:45 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 05 Aug 2014 11:03:45 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <53E0F507.40409@redhat.com> References: <53E0E0F3.80605@redhat.com> <53E0E392.2040804@redhat.com> <53E0E856.10001@redhat.com> <53E0F507.40409@redhat.com> Message-ID: <53E10061.6030006@redhat.com> On 08/05/2014 10:15 AM, Brian Stansberry wrote: > On 8/5/14, 9:21 AM, David M. Lloyd wrote: >> On 08/05/2014 09:00 AM, Brian Stansberry wrote: >>> On 8/5/14, 8:49 AM, David M. Lloyd wrote: >>>> On 08/05/2014 02:42 AM, Heiko Braun wrote: >>>>> TL;DR: A proposal for improving parts of the management API that deal with static resource definitions >>>>> >>>>> Background: >>>>> >>>>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation. >>>>> >>>>> Problem: >>>>> >>>>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.: >>>>> >>>>> /subsystem=datasources/data-source=ExampleDS >>>>> >>>>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources. >>>>> >>>>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.: >>>>> >>>>> /subsystem=ejb3/service=[async | remote | timer-service] >>>> >>>> We've solved this a different way in the "next" management model. We >>>> introduce the concept of an "attribute group". In your example we'd >>>> perhaps have an attribute group for async, one for remote, and one for >>>> timer-service within the root resource. >>>> >>>> An attribute group is something like a composition resource. They can >>>> be optional or mandatory, and they can be named or anonymous. >>>> >>>> A named attribute group would be separately addressable as a unit, or >>>> can be accessed using a qualifier syntax e.g. "thegroup.theattribute". >>>> Also they can be arbitrarily nested. >>>> >>>> An anonymous attribute group is just a logical grouping which is only >>>> relevant to the server Java API itself and is invisible to the so-called >>>> "DMR" or REST style API. We can use these groups to retrofit existing >>>> subsystems without breaking compatibility (this gives certain code reuse >>>> benefits which are not important to this discussion). >>>> >>>> This way we preserve the invariant that all attributes with a given key >>>> have a related type (we also introduce the concept of type hierarchies >>>> though, which mitigates this constraint in a different way, but that's >>>> not related to this). >>>> >>> >>> Is there a notion of null/undefined for the attribute group itself, as >>> opposed to the individual attributes? >> >> Yes, but only for "optional" attribute groups. IOW the resource author >> can decide if that's appropriate or not. >> >> I have not yet completely worked out how manipulation operations would >> look for this. I think it may be closely tied in to what we do for >> so-called "complex" attributes though. >> >>> That's a conceptual distinction -- a resource doesn't exist unless it's >>> added. >> >> Yes, it's a distinct concept. However (at least for the given example) >> I think that an attribute group is a better fit. The problem with >> "squatters" is that they don't really have a common API, and yet they >> aren't really independent - it's just a way of addressing the >> composition of a parent resource. > > Where is the boundary for "independent"? > > I've concluded that over time we've gone too far toward making resources > out of things that are not independent, with resources used for things > that really aren't at all. But is service=remote not semi-independent? > It adds an entire chunk of functionality, including a requirement for > the presence of a remoting subsystem. Yeah that is true, conceptually. There is possibly a line where subsystems might themselves have subsystems. But in this case, maybe it would sometimes make sense to use the existing profile/subsystem relationship as a prototype? Also, if a subsystem is truly in two or more parts, then we should consider having separate subsystems for the parts (consider PicketLink as a recent example). This isn't the case for your example, but it does clear out some more possible candidate cases. If there remains a gray area where a subsystem has specific constituent functionality *and* there is a large enough degree of independence between the enclosing and enclosed resource that an optional attribute group seems inappropriate (but not large enough to warrant a separate subsystem), *that* would be the remaining case that would support these singleton sub-resources. We just have to identify the qualifying criteria for this distinction. > I see how it could be treated as just another aspect of the parent. I'd > like to have a clearly explainable boundary line. Maybe a bit fuzzy, but > something clear for 98% of the cases. Yeah I agree, clearly delineating the cases is key. If we have three or four mechanisms which are similar, but there's no clear guideline as to what is appropriate and when, we're going to end up with a mess. Going through the existing model again with this in mind might be the right next step, and seeing if it's possible to clearly categorize existing cases into "should be an attribute group" versus "should be a singleton resource", would be a great way to validate the logic of the idea. If we can do so in a fairly logical and deterministic manner, then I can look into seeing if I can make sub-resources work this way in the new model. The main conceptual issue here is the addressing scheme - in particular using the value to select resource type instead of the key. This introduces a third major way to identify sub-resources in addition to the normal map-like structure and the profile/subsystem scheme. If we can avoid this then that makes this more feasible. -- - DML From darran.lofthouse at jboss.com Tue Aug 5 12:07:05 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 05 Aug 2014 17:07:05 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split Message-ID: <53E10129.10406@jboss.com> After forward porting some schema changes from EAP to WildFly it has become apparent that it is a little cumbersome to work with AppClientXml as it's implementation is dependent on the schema definitions in wildfly-core and yet it lives in wildfly. The first point I realise is that the root element parsed by AppClientXml is 'server' however it only accepts a subset of the elements defined as supported by the 'server' element. Could it make sense for version 3 of the schema and onward to have a new root element 'client'? Secondly this could open up the option to have the client element defined in a schema in wildfly and just reference the types that are in wildfly-core. wildfly would then contain the parsing code for client and the parsing code for the referenced types would be in wildfly-core and accessed through an agreed API that we maintain for compatibility. Regards, Darran Lofthouse. From brian.stansberry at redhat.com Tue Aug 5 12:20:52 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 11:20:52 -0500 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E10129.10406@jboss.com> References: <53E10129.10406@jboss.com> Message-ID: <53E10464.8000808@redhat.com> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: > After forward porting some schema changes from EAP to WildFly it has > become apparent that it is a little cumbersome to work with AppClientXml > as it's implementation is dependent on the schema definitions in > wildfly-core and yet it lives in wildfly. > > The first point I realise is that the root element parsed by > AppClientXml is 'server' however it only accepts a subset of the > elements defined as supported by the 'server' element. Could it make > sense for version 3 of the schema and onward to have a new root element > 'client'? > > Secondly this could open up the option to have the client element > defined in a schema in wildfly and just reference the types that are in > wildfly-core. wildfly would then contain the parsing code for client > and the parsing code for the referenced types would be in wildfly-core > and accessed through an agreed API that we maintain for compatibility. > Perhaps. I know it's wrong but I'm tempted to pull the whole thing into core. I don't much like having core parsing stuff as part of the API exposed by core. If we add an API it needs to be really coarse grained. The only tie this class has to anything outside of core is one logger message that at a glance looks like something that probably already exists in core. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Tue Aug 5 12:26:10 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 05 Aug 2014 17:26:10 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E10464.8000808@redhat.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> Message-ID: <53E105A2.4070902@jboss.com> On 05/08/14 17:20, Brian Stansberry wrote: > On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >> After forward porting some schema changes from EAP to WildFly it has >> become apparent that it is a little cumbersome to work with AppClientXml >> as it's implementation is dependent on the schema definitions in >> wildfly-core and yet it lives in wildfly. >> >> The first point I realise is that the root element parsed by >> AppClientXml is 'server' however it only accepts a subset of the >> elements defined as supported by the 'server' element. Could it make >> sense for version 3 of the schema and onward to have a new root element >> 'client'? >> >> Secondly this could open up the option to have the client element >> defined in a schema in wildfly and just reference the types that are in >> wildfly-core. wildfly would then contain the parsing code for client >> and the parsing code for the referenced types would be in wildfly-core >> and accessed through an agreed API that we maintain for compatibility. >> > > Perhaps. I know it's wrong but I'm tempted to pull the whole thing into > core. I don't much like having core parsing stuff as part of the API > exposed by core. Yeah feel the same on that one, trying to find a solution that isn't wrong. > If we add an API it needs to be really coarse grained. Yes I was thinking something corse grained to the level of: - parseProfile() parseSocketBindings() Each of these methods would then need to be responsible for their own version check. > The only tie this class has to anything outside of core is one logger > message that at a glance looks like something that probably already > exists in core. > > From emartins at redhat.com Tue Aug 5 12:26:31 2014 From: emartins at redhat.com (Eduardo Martins) Date: Tue, 5 Aug 2014 17:26:31 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E10129.10406@jboss.com> References: <53E10129.10406@jboss.com> Message-ID: IMHO app client xml should use a config template like standalone and domain, and be filled with specific subsystem supplements. ?E On 05 Aug 2014, at 17:07, Darran Lofthouse wrote: > After forward porting some schema changes from EAP to WildFly it has > become apparent that it is a little cumbersome to work with AppClientXml > as it's implementation is dependent on the schema definitions in > wildfly-core and yet it lives in wildfly. > > The first point I realise is that the root element parsed by > AppClientXml is 'server' however it only accepts a subset of the > elements defined as supported by the 'server' element. Could it make > sense for version 3 of the schema and onward to have a new root element > 'client'? > > Secondly this could open up the option to have the client element > defined in a schema in wildfly and just reference the types that are in > wildfly-core. wildfly would then contain the parsing code for client > and the parsing code for the referenced types would be in wildfly-core > and accessed through an agreed API that we maintain for compatibility. > > Regards, > Darran Lofthouse. > > _______________________________________________ > 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 Aug 5 12:31:12 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 05 Aug 2014 17:31:12 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: References: <53E10129.10406@jboss.com> Message-ID: <53E106D0.5090703@jboss.com> At this point I am more interested in the schemas and parsers, assembly of the default configs is a new issue on it's own ;-) On 05/08/14 17:26, Eduardo Martins wrote: > IMHO app client xml should use a config template like standalone and domain, and be filled with specific subsystem supplements. > > ?E > > On 05 Aug 2014, at 17:07, Darran Lofthouse wrote: > >> After forward porting some schema changes from EAP to WildFly it has >> become apparent that it is a little cumbersome to work with AppClientXml >> as it's implementation is dependent on the schema definitions in >> wildfly-core and yet it lives in wildfly. >> >> The first point I realise is that the root element parsed by >> AppClientXml is 'server' however it only accepts a subset of the >> elements defined as supported by the 'server' element. Could it make >> sense for version 3 of the schema and onward to have a new root element >> 'client'? >> >> Secondly this could open up the option to have the client element >> defined in a schema in wildfly and just reference the types that are in >> wildfly-core. wildfly would then contain the parsing code for client >> and the parsing code for the referenced types would be in wildfly-core >> and accessed through an agreed API that we maintain for compatibility. >> >> Regards, >> Darran Lofthouse. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From smarlow at redhat.com Tue Aug 5 12:45:04 2014 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 05 Aug 2014 12:45:04 -0400 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: References: <42030287-3101-4E7E-B4BF-7CB61C7554C9@gmx.net> Message-ID: <53E10A10.50902@redhat.com> Thanks for the complements Andrej! :-) Sanne, please see in-line below. On 08/05/2014 09:49 AM, Sanne Grinovero wrote: > Hi Andrej, > that's an excellent point. > > I also don't want to make it harder for users to play with the latest > versions we'll be releasing - normally at a higher pace than WildFly. I'm not sure that you need to sync up with WildFly as much as the Hibernate ORM project. For example, > > I guess I'll need learn more about writing a subsystem to make sure > these options are covered. If Hibernate Search is a part of the Hibernate ORM module, like Envers is, that could make integration easy enough for Hibernate Search and users that want to package Hibernate ORM with their application. They either also include Hibernate Search or not. If applications include Hibernate ORM but no Hibernate Search, they can't use Hibernate Search. A bigger problem though is that bundling Hibernate Search with the application, likely means that the application server version of Infinispan (already configured and ready to work with clustering), will not be usable. Another related issue is that Hibernate 3.x depends on an older version of Infinispan, so when Hibernate 3.x is used on WildFly, clustering of the second level cache will not work (even when Hibernate 3.x is used as a wildfly/modules (static) module). The same will occur with other versions of Hibernate as well. In theory, we could externalize clustering integration to be external to the Hibernate ORM codebase (in Jipijapa). I've done some experimentation with that but not too far (more for EclipseLink/OpenJpa 2lc clustering but we could see some benefit to Hibernate also). Scott > > Thanks all, > Sanne > > On 4 August 2014 20:43, Andrej Golovnin wrote: >> Hi Sanne, >> >>> I see no reasons to not enable it by default, following the same >>> activation rules of other Hibernate dependencies: it's very >>> conservative about not auto-enabling itself when not needed. >>> >> >> It is OK as long as it will be still possible to bundle Hibernate Search >> within an application and Hibernate would use the bundled version of >> Hibernate Search. >> >> Not all users want to use Hibernate and Hibernate Search, >> which are delivered with WildFly. >> >> For Hibernate we have a perfect solution developed by Scott, which >> allows WildFly to use Hibernate packaged inside of an application. >> At this place a big thanks to Scott for this wonderful solution! It works great! >> The same should be possible with Hibernate Search. >> >> Best regards, >> Andrej Golovnin > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From arjan.tijms at gmail.com Tue Aug 5 13:03:02 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 5 Aug 2014 19:03:02 +0200 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E0DCD4.8000406@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> Message-ID: On Tuesday, August 5, 2014, Bill Burke wrote: > > Honestly though, I think this talk of EJB pooling is ridiculous. > Component layers like CDI and JAX-RS don't have pooled architectures for > their per-request objects. True, but the problem with EJB is that it has always been implied that stateless beans are pooled. And indeed, many servers have done so. As a result, various developers have implemented their beans with the assumption that there would be pooling. That code is now seeing (performance) issues. I think it's reasonable to assume that in many cases pooling is unnecessary, but that occasionally it's needed. One solution to this could be an explicit @Pooled annotation for general usage with (CDI) managed beans. Kind regards, Arjan Tijms > Also, in an average application, there are > multiple orders of magnitude more non component classes that are being > instantiated per request. Just think of all the Strings created by a > simple HTTP request. > > You want a better focus? How about JSON/XML marshalling? Which could > make things much easier to maintain then the hand-coded parsers that > Wildfly uses to parse config. And much faster and less memory at > runtime for SOAP and JAX-RS request that currently rely on java reflection. > > You could go research perfect hashing algorithms for URL matching with > servlets and JAX-RS. > > You could go do some perf analysis of all of our frameworks to make > memory reduction and speed recommendations or even Pull Requests. > > You could visit each major project and make sure our automated builds > have and can run automated stress tests and are measured against > previous versions. > > Or you could just focus on these silly benchmarks that test no-op HTTP > and EJB requests. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.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/20140805/f4a84fb0/attachment.html From darran.lofthouse at jboss.com Tue Aug 5 13:16:45 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 05 Aug 2014 18:16:45 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E105A2.4070902@jboss.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> <53E105A2.4070902@jboss.com> Message-ID: <53E1117D.6020702@jboss.com> Just to split this into two decisions: - Is there any reason the root element needs to be 'server' even though the server definition differs depending on what is parsing it or should we add a new root element 'client'? On 05/08/14 17:26, Darran Lofthouse wrote: > > > On 05/08/14 17:20, Brian Stansberry wrote: >> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >>> After forward porting some schema changes from EAP to WildFly it has >>> become apparent that it is a little cumbersome to work with AppClientXml >>> as it's implementation is dependent on the schema definitions in >>> wildfly-core and yet it lives in wildfly. >>> >>> The first point I realise is that the root element parsed by >>> AppClientXml is 'server' however it only accepts a subset of the >>> elements defined as supported by the 'server' element. Could it make >>> sense for version 3 of the schema and onward to have a new root element >>> 'client'? >>> >>> Secondly this could open up the option to have the client element >>> defined in a schema in wildfly and just reference the types that are in >>> wildfly-core. wildfly would then contain the parsing code for client >>> and the parsing code for the referenced types would be in wildfly-core >>> and accessed through an agreed API that we maintain for compatibility. >>> >> >> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >> core. I don't much like having core parsing stuff as part of the API >> exposed by core. > > Yeah feel the same on that one, trying to find a solution that isn't wrong. > >> If we add an API it needs to be really coarse grained. > > Yes I was thinking something corse grained to the level of: - > parseProfile() > parseSocketBindings() > > Each of these methods would then need to be responsible for their own > version check. > >> The only tie this class has to anything outside of core is one logger >> message that at a glance looks like something that probably already >> exists in core. >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From emartins at redhat.com Tue Aug 5 13:27:47 2014 From: emartins at redhat.com (Eduardo Martins) Date: Tue, 5 Aug 2014 18:27:47 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E106D0.5090703@jboss.com> References: <53E10129.10406@jboss.com> <53E106D0.5090703@jboss.com> Message-ID: And I?m more interested in having app client to follow the other configs, since I?m working on that for the new wildfly build tools to assemble feature packs and servers :-) All the code works with a config template plus a set of subsystem config files, I don?t really see a reason to not fix it all now. ?E On 05 Aug 2014, at 17:31, Darran Lofthouse wrote: > At this point I am more interested in the schemas and parsers, assembly of the default configs is a new issue on it's own ;-) > > On 05/08/14 17:26, Eduardo Martins wrote: >> IMHO app client xml should use a config template like standalone and domain, and be filled with specific subsystem supplements. >> >> ?E >> >> On 05 Aug 2014, at 17:07, Darran Lofthouse wrote: >> >>> After forward porting some schema changes from EAP to WildFly it has >>> become apparent that it is a little cumbersome to work with AppClientXml >>> as it's implementation is dependent on the schema definitions in >>> wildfly-core and yet it lives in wildfly. >>> >>> The first point I realise is that the root element parsed by >>> AppClientXml is 'server' however it only accepts a subset of the >>> elements defined as supported by the 'server' element. Could it make >>> sense for version 3 of the schema and onward to have a new root element >>> 'client'? >>> >>> Secondly this could open up the option to have the client element >>> defined in a schema in wildfly and just reference the types that are in >>> wildfly-core. wildfly would then contain the parsing code for client >>> and the parsing code for the referenced types would be in wildfly-core >>> and accessed through an agreed API that we maintain for compatibility. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> _______________________________________________ >>> 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 Aug 5 13:38:09 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 05 Aug 2014 18:38:09 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: References: <53E10129.10406@jboss.com> <53E106D0.5090703@jboss.com> Message-ID: <53E11681.10706@jboss.com> LOL, yeah I am not saying your interests are invalid - just not the topic I am trying to cover on this thread ;-) On 05/08/14 18:27, Eduardo Martins wrote: > And I?m more interested in having app client to follow the other configs, since I?m working on that for the new wildfly build tools to assemble feature packs and servers :-) > > All the code works with a config template plus a set of subsystem config files, I don?t really see a reason to not fix it all now. > > ?E > > On 05 Aug 2014, at 17:31, Darran Lofthouse wrote: > >> At this point I am more interested in the schemas and parsers, assembly of the default configs is a new issue on it's own ;-) >> >> On 05/08/14 17:26, Eduardo Martins wrote: >>> IMHO app client xml should use a config template like standalone and domain, and be filled with specific subsystem supplements. >>> >>> ?E >>> >>> On 05 Aug 2014, at 17:07, Darran Lofthouse wrote: >>> >>>> After forward porting some schema changes from EAP to WildFly it has >>>> become apparent that it is a little cumbersome to work with AppClientXml >>>> as it's implementation is dependent on the schema definitions in >>>> wildfly-core and yet it lives in wildfly. >>>> >>>> The first point I realise is that the root element parsed by >>>> AppClientXml is 'server' however it only accepts a subset of the >>>> elements defined as supported by the 'server' element. Could it make >>>> sense for version 3 of the schema and onward to have a new root element >>>> 'client'? >>>> >>>> Secondly this could open up the option to have the client element >>>> defined in a schema in wildfly and just reference the types that are in >>>> wildfly-core. wildfly would then contain the parsing code for client >>>> and the parsing code for the referenced types would be in wildfly-core >>>> and accessed through an agreed API that we maintain for compatibility. >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > From hamedhatami2012 at gmail.com Tue Aug 5 13:39:13 2014 From: hamedhatami2012 at gmail.com (Hamed Hatami) Date: Tue, 5 Aug 2014 22:09:13 +0430 Subject: [wildfly-dev] MDBs in JBoss EAP 6.x/Wildfly 8.x Message-ID: Hi, I use MDB in my project under JBoss EAP 6.2/Wildfly 8.1 and change my MOM from HornetQ to IBM Websphere MQ with resource adapter but when jboss startup the connection count grow until my MOM crashed and we have to restart the jboss after 4 or 5 hours , what happened? Regards, Hamed Hatami. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140805/043e3800/attachment.html From brian.stansberry at redhat.com Tue Aug 5 13:44:31 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 12:44:31 -0500 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E1117D.6020702@jboss.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> <53E105A2.4070902@jboss.com> <53E1117D.6020702@jboss.com> Message-ID: <53E117FF.5020704@redhat.com> Just compatibility. Changing the "standard" element name means updating docs, examples etc. We are going to have to parse legacy documents with 'server' no matter what. On 8/5/14, 12:16 PM, Darran Lofthouse wrote: > Just to split this into two decisions: - > > Is there any reason the root element needs to be 'server' even though > the server definition differs depending on what is parsing it or should > we add a new root element 'client'? > > On 05/08/14 17:26, Darran Lofthouse wrote: >> >> >> On 05/08/14 17:20, Brian Stansberry wrote: >>> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >>>> After forward porting some schema changes from EAP to WildFly it has >>>> become apparent that it is a little cumbersome to work with AppClientXml >>>> as it's implementation is dependent on the schema definitions in >>>> wildfly-core and yet it lives in wildfly. >>>> >>>> The first point I realise is that the root element parsed by >>>> AppClientXml is 'server' however it only accepts a subset of the >>>> elements defined as supported by the 'server' element. Could it make >>>> sense for version 3 of the schema and onward to have a new root element >>>> 'client'? >>>> >>>> Secondly this could open up the option to have the client element >>>> defined in a schema in wildfly and just reference the types that are in >>>> wildfly-core. wildfly would then contain the parsing code for client >>>> and the parsing code for the referenced types would be in wildfly-core >>>> and accessed through an agreed API that we maintain for compatibility. >>>> >>> >>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>> core. I don't much like having core parsing stuff as part of the API >>> exposed by core. >> >> Yeah feel the same on that one, trying to find a solution that isn't wrong. >> >>> If we add an API it needs to be really coarse grained. >> >> Yes I was thinking something corse grained to the level of: - >> parseProfile() >> parseSocketBindings() >> >> Each of these methods would then need to be responsible for their own >> version check. >> >>> The only tie this class has to anything outside of core is one logger >>> message that at a glance looks like something that probably already >>> exists in core. >>> >>> >> _______________________________________________ >> 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 brian.stansberry at redhat.com Tue Aug 5 13:51:53 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 12:51:53 -0500 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <874726742.21577492.1406659447392.JavaMail.zimbra@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> <660940694.19299854.1406292550805.JavaMail.zimbra@redhat.com> <53D2CECE.8000400@redhat.com> <874726742.21577492.1406659447392.JavaMail.zimbra@redhat.com> Message-ID: <53E119B9.7040206@redhat.com> On 7/29/14, 1:44 PM, Liz Clayton wrote: > Hi, > > Thanks for answering my questions! > > ----- Original Message ----- >> From: "Brian Stansberry" >> To: "Liz Clayton" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Friday, July 25, 2014 5:40:30 PM >> Subject: Re: [wildfly-dev] Domain Overview design >> > ... >>> The boxes are irregular on 16 because they were intended to display mini >>> heatmaps, stacked. And unlike the domain-view version (pg15) where the >>> size of the box would be driven by # of servers - the mini ones could be >>> scaled by some other metric (throughput or etc.). But I didn't really have >>> that information, so I made the boxes uniformly sized. >>> >> >> I see; so the thought was perhaps the user could choose a scaling factor >> or something? > > I hadn't thought about it being a user selection, but that's an interesting idea. > > ... >>>> There's also a similar notion regarding how consistent the server's >>>> running state is with its persistent configuration. Admins can make >>>> configuration changes that will not take effect until the server is >>>> reloaded or restarted. >>> >>> Would that directly affect its availability status? >>> >> >> No, it wouldn't. The server goes into this state when the admin makes a >> config change that the server can't apply to its running services >> without affecting their ability to handle end-user requests. The server >> doesn't "just do it", it goes into this state which lets the admin know >> they need to take an action that *will* temporarily affect availability. >> >>>> I'm not sure if those things are well represented on a green-yellow-red >>>> color continuum because they are somewhat different from server health. >>>> But they are important pieces of data to visualize. > > So there's server health (availability), & server "state", and they are both useful bits of high-level info. > Just an FYI -- there was a thread on this list in June about exposing status information related to graceful shutdown. It's a pretty convoluted thread, but here's a hopefully useful conclusion point: http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html >>> yes, great to know about. >>> >>>> "How does the Alerts tab fit in with the *current* Notification message >>>> queue?" >>>> >>>> Heiko Braun knows better, but I don't see a close fit. The current queue >>>> isn't really based on any sort of server-push of events. The console >>>> makes administrative requests and gets responses; if relevant that >>>> request/response results in stuff in the queue. But anything that >>>> happens outside of those requests/responses is unknown to the console. >>> >>> So there are events happening on the system, that could affect >>> availability, which will not show up in the message queue? >>> >> >> Absolutely. The console only knows what it specifically asks or the >> effect of changes it makes, plus a small bit of status information that >> gets piggy-backed in the response to requests (i.e. that the server is >> in reload/restart-required state.) But the user's app could be throwing >> errors all over the place, resources like memory or thread pools could >> be overtaxed, etc, and the console would have no clue unless it check >> those specific things. > > OK, thanks! > > -Liz > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Tue Aug 5 14:00:57 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 05 Aug 2014 19:00:57 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E117FF.5020704@redhat.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> <53E105A2.4070902@jboss.com> <53E1117D.6020702@jboss.com> <53E117FF.5020704@redhat.com> Message-ID: <53E11BD9.70200@jboss.com> On 05/08/14 18:44, Brian Stansberry wrote: > Just compatibility. Changing the "standard" element name means updating > docs, examples etc. Personally I think that is just something we have to accept we will have to do - at the moment we have a parser that follows a schema 'a bit' and I don't think docs and examples are a strong enough justification to keep it that way for WF9 and beyond. > We are going to have to parse legacy documents with 'server' no matter what. +1 which is why I am suggesting we fix it from version 3. > On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >> Just to split this into two decisions: - >> >> Is there any reason the root element needs to be 'server' even though >> the server definition differs depending on what is parsing it or should >> we add a new root element 'client'? >> >> On 05/08/14 17:26, Darran Lofthouse wrote: >>> >>> >>> On 05/08/14 17:20, Brian Stansberry wrote: >>>> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >>>>> After forward porting some schema changes from EAP to WildFly it has >>>>> become apparent that it is a little cumbersome to work with AppClientXml >>>>> as it's implementation is dependent on the schema definitions in >>>>> wildfly-core and yet it lives in wildfly. >>>>> >>>>> The first point I realise is that the root element parsed by >>>>> AppClientXml is 'server' however it only accepts a subset of the >>>>> elements defined as supported by the 'server' element. Could it make >>>>> sense for version 3 of the schema and onward to have a new root element >>>>> 'client'? >>>>> >>>>> Secondly this could open up the option to have the client element >>>>> defined in a schema in wildfly and just reference the types that are in >>>>> wildfly-core. wildfly would then contain the parsing code for client >>>>> and the parsing code for the referenced types would be in wildfly-core >>>>> and accessed through an agreed API that we maintain for compatibility. >>>>> >>>> >>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>> core. I don't much like having core parsing stuff as part of the API >>>> exposed by core. >>> >>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>> >>>> If we add an API it needs to be really coarse grained. >>> >>> Yes I was thinking something corse grained to the level of: - >>> parseProfile() >>> parseSocketBindings() >>> >>> Each of these methods would then need to be responsible for their own >>> version check. >>> >>>> The only tie this class has to anything outside of core is one logger >>>> message that at a glance looks like something that probably already >>>> exists in core. >>>> >>>> >>> _______________________________________________ >>> 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 Aug 5 14:05:57 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 13:05:57 -0500 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E11BD9.70200@jboss.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> <53E105A2.4070902@jboss.com> <53E1117D.6020702@jboss.com> <53E117FF.5020704@redhat.com> <53E11BD9.70200@jboss.com> Message-ID: <53E11D05.5020903@redhat.com> TBH, I don't care much one way or the other. :) Using 'server' sucks; changing names invariable comes back and bites you with tedious work when you're least in the mood. So, choose your poison. If you prefer the 'client' poison, that's ok with me. Wait for Stuart to have a chance to read this though as he's the poor soul who's had to do the most work in this area. On 8/5/14, 1:00 PM, Darran Lofthouse wrote: > On 05/08/14 18:44, Brian Stansberry wrote: >> Just compatibility. Changing the "standard" element name means updating >> docs, examples etc. > > Personally I think that is just something we have to accept we will have > to do - at the moment we have a parser that follows a schema 'a bit' and > I don't think docs and examples are a strong enough justification to > keep it that way for WF9 and beyond. > >> We are going to have to parse legacy documents with 'server' no matter what. > > +1 which is why I am suggesting we fix it from version 3. > > >> On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >>> Just to split this into two decisions: - >>> >>> Is there any reason the root element needs to be 'server' even though >>> the server definition differs depending on what is parsing it or should >>> we add a new root element 'client'? >>> >>> On 05/08/14 17:26, Darran Lofthouse wrote: >>>> >>>> >>>> On 05/08/14 17:20, Brian Stansberry wrote: >>>>> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >>>>>> After forward porting some schema changes from EAP to WildFly it has >>>>>> become apparent that it is a little cumbersome to work with AppClientXml >>>>>> as it's implementation is dependent on the schema definitions in >>>>>> wildfly-core and yet it lives in wildfly. >>>>>> >>>>>> The first point I realise is that the root element parsed by >>>>>> AppClientXml is 'server' however it only accepts a subset of the >>>>>> elements defined as supported by the 'server' element. Could it make >>>>>> sense for version 3 of the schema and onward to have a new root element >>>>>> 'client'? >>>>>> >>>>>> Secondly this could open up the option to have the client element >>>>>> defined in a schema in wildfly and just reference the types that are in >>>>>> wildfly-core. wildfly would then contain the parsing code for client >>>>>> and the parsing code for the referenced types would be in wildfly-core >>>>>> and accessed through an agreed API that we maintain for compatibility. >>>>>> >>>>> >>>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>>> core. I don't much like having core parsing stuff as part of the API >>>>> exposed by core. >>>> >>>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>>> >>>>> If we add an API it needs to be really coarse grained. >>>> >>>> Yes I was thinking something corse grained to the level of: - >>>> parseProfile() >>>> parseSocketBindings() >>>> >>>> Each of these methods would then need to be responsible for their own >>>> version check. >>>> >>>>> The only tie this class has to anything outside of core is one logger >>>>> message that at a glance looks like something that probably already >>>>> exists in core. >>>>> >>>>> >>>> _______________________________________________ >>>> 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 Aug 5 14:10:09 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 05 Aug 2014 19:10:09 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E11D05.5020903@redhat.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> <53E105A2.4070902@jboss.com> <53E1117D.6020702@jboss.com> <53E117FF.5020704@redhat.com> <53E11BD9.70200@jboss.com> <53E11D05.5020903@redhat.com> Message-ID: <53E11E01.1060207@jboss.com> On 05/08/14 19:05, Brian Stansberry wrote: > TBH, I don't care much one way or the other. :) Using 'server' sucks; > changing names invariable comes back and bites you with tedious work > when you're least in the mood. So, choose your poison. If you prefer the > 'client' poison, that's ok with me. Well it is not as if this isn't already biting us ;-) I think this class has bitten me a couple of times now. > Wait for Stuart to have a chance to read this though as he's the poor > soul who's had to do the most work in this area. Sure already 7pm here so not going to be a task for tonight. > On 8/5/14, 1:00 PM, Darran Lofthouse wrote: >> On 05/08/14 18:44, Brian Stansberry wrote: >>> Just compatibility. Changing the "standard" element name means updating >>> docs, examples etc. >> >> Personally I think that is just something we have to accept we will have >> to do - at the moment we have a parser that follows a schema 'a bit' and >> I don't think docs and examples are a strong enough justification to >> keep it that way for WF9 and beyond. >> >>> We are going to have to parse legacy documents with 'server' no matter what. >> >> +1 which is why I am suggesting we fix it from version 3. >> >> >>> On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >>>> Just to split this into two decisions: - >>>> >>>> Is there any reason the root element needs to be 'server' even though >>>> the server definition differs depending on what is parsing it or should >>>> we add a new root element 'client'? >>>> >>>> On 05/08/14 17:26, Darran Lofthouse wrote: >>>>> >>>>> >>>>> On 05/08/14 17:20, Brian Stansberry wrote: >>>>>> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >>>>>>> After forward porting some schema changes from EAP to WildFly it has >>>>>>> become apparent that it is a little cumbersome to work with AppClientXml >>>>>>> as it's implementation is dependent on the schema definitions in >>>>>>> wildfly-core and yet it lives in wildfly. >>>>>>> >>>>>>> The first point I realise is that the root element parsed by >>>>>>> AppClientXml is 'server' however it only accepts a subset of the >>>>>>> elements defined as supported by the 'server' element. Could it make >>>>>>> sense for version 3 of the schema and onward to have a new root element >>>>>>> 'client'? >>>>>>> >>>>>>> Secondly this could open up the option to have the client element >>>>>>> defined in a schema in wildfly and just reference the types that are in >>>>>>> wildfly-core. wildfly would then contain the parsing code for client >>>>>>> and the parsing code for the referenced types would be in wildfly-core >>>>>>> and accessed through an agreed API that we maintain for compatibility. >>>>>>> >>>>>> >>>>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>>>> core. I don't much like having core parsing stuff as part of the API >>>>>> exposed by core. >>>>> >>>>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>>>> >>>>>> If we add an API it needs to be really coarse grained. >>>>> >>>>> Yes I was thinking something corse grained to the level of: - >>>>> parseProfile() >>>>> parseSocketBindings() >>>>> >>>>> Each of these methods would then need to be responsible for their own >>>>> version check. >>>>> >>>>>> The only tie this class has to anything outside of core is one logger >>>>>> message that at a glance looks like something that probably already >>>>>> exists in core. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 brian.stansberry at redhat.com Tue Aug 5 14:13:07 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 05 Aug 2014 13:13:07 -0500 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E11E01.1060207@jboss.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> <53E105A2.4070902@jboss.com> <53E1117D.6020702@jboss.com> <53E117FF.5020704@redhat.com> <53E11BD9.70200@jboss.com> <53E11D05.5020903@redhat.com> <53E11E01.1060207@jboss.com> Message-ID: <53E11EB3.3020908@redhat.com> On 8/5/14, 1:10 PM, Darran Lofthouse wrote: > On 05/08/14 19:05, Brian Stansberry wrote: >> TBH, I don't care much one way or the other. :) Using 'server' sucks; >> changing names invariable comes back and bites you with tedious work >> when you're least in the mood. So, choose your poison. If you prefer the >> 'client' poison, that's ok with me. > > Well it is not as if this isn't already biting us ;-) > > I think this class has bitten me a couple of times now. > Me too. >> Wait for Stuart to have a chance to read this though as he's the poor >> soul who's had to do the most work in this area. > > Sure already 7pm here so not going to be a task for tonight. > >> On 8/5/14, 1:00 PM, Darran Lofthouse wrote: >>> On 05/08/14 18:44, Brian Stansberry wrote: >>>> Just compatibility. Changing the "standard" element name means updating >>>> docs, examples etc. >>> >>> Personally I think that is just something we have to accept we will have >>> to do - at the moment we have a parser that follows a schema 'a bit' and >>> I don't think docs and examples are a strong enough justification to >>> keep it that way for WF9 and beyond. >>> >>>> We are going to have to parse legacy documents with 'server' no matter what. >>> >>> +1 which is why I am suggesting we fix it from version 3. >>> >>> >>>> On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >>>>> Just to split this into two decisions: - >>>>> >>>>> Is there any reason the root element needs to be 'server' even though >>>>> the server definition differs depending on what is parsing it or should >>>>> we add a new root element 'client'? >>>>> >>>>> On 05/08/14 17:26, Darran Lofthouse wrote: >>>>>> >>>>>> >>>>>> On 05/08/14 17:20, Brian Stansberry wrote: >>>>>>> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >>>>>>>> After forward porting some schema changes from EAP to WildFly it has >>>>>>>> become apparent that it is a little cumbersome to work with AppClientXml >>>>>>>> as it's implementation is dependent on the schema definitions in >>>>>>>> wildfly-core and yet it lives in wildfly. >>>>>>>> >>>>>>>> The first point I realise is that the root element parsed by >>>>>>>> AppClientXml is 'server' however it only accepts a subset of the >>>>>>>> elements defined as supported by the 'server' element. Could it make >>>>>>>> sense for version 3 of the schema and onward to have a new root element >>>>>>>> 'client'? >>>>>>>> >>>>>>>> Secondly this could open up the option to have the client element >>>>>>>> defined in a schema in wildfly and just reference the types that are in >>>>>>>> wildfly-core. wildfly would then contain the parsing code for client >>>>>>>> and the parsing code for the referenced types would be in wildfly-core >>>>>>>> and accessed through an agreed API that we maintain for compatibility. >>>>>>>> >>>>>>> >>>>>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>>>>> core. I don't much like having core parsing stuff as part of the API >>>>>>> exposed by core. >>>>>> >>>>>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>>>>> >>>>>>> If we add an API it needs to be really coarse grained. >>>>>> >>>>>> Yes I was thinking something corse grained to the level of: - >>>>>> parseProfile() >>>>>> parseSocketBindings() >>>>>> >>>>>> Each of these methods would then need to be responsible for their own >>>>>> version check. >>>>>> >>>>>>> The only tie this class has to anything outside of core is one logger >>>>>>> message that at a glance looks like something that probably already >>>>>>> exists in core. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> > _______________________________________________ > 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 tomaz.cerar at gmail.com Tue Aug 5 14:32:40 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 5 Aug 2014 20:32:40 +0200 Subject: [wildfly-dev] MDBs in JBoss EAP 6.x/Wildfly 8.x In-Reply-To: References: Message-ID: Hi, this mailing list is for discussing future development of wildfly not users list. use forums for that: for WildFly https://community.jboss.org/en/wildfly for EAP https://community.jboss.org/en/jbosseap and given that you use EAP 6.2 you could / should open a support case in support portal which you can find at http://access.redhat.com/ -- tomaz On Tue, Aug 5, 2014 at 7:39 PM, Hamed Hatami wrote: > Hi, > > I use MDB in my project under JBoss EAP 6.2/Wildfly 8.1 and change my MOM > from HornetQ to IBM Websphere MQ with resource adapter but when jboss > startup the connection count grow until my MOM crashed and we have to > restart the jboss after 4 or 5 hours , what happened? > > 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/20140805/de93724c/attachment.html From anmiller at redhat.com Tue Aug 5 15:49:21 2014 From: anmiller at redhat.com (Andrig Miller) Date: Tue, 5 Aug 2014 15:49:21 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> <2059247.3549.1407193183315.JavaMail.andrig@worklaptop.miller.org> <53E023B8.1020508@redhat.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> Message-ID: <1869664.826.1407268158747.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Jason Greene" > To: "Andrig Miller" > Cc: "Bill Burke" , wildfly-dev at lists.jboss.org > Sent: Tuesday, August 5, 2014 8:15:47 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > On Aug 5, 2014, at 8:43 AM, Andrig Miller > wrote: > > > > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: "James Livingston" > >> Cc: wildfly-dev at lists.jboss.org > >> Sent: Tuesday, August 5, 2014 7:32:04 AM > >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > >> > >> > >> > >> On 8/4/2014 8:44 PM, James Livingston wrote: > >>> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote: > >>>> I always liked the ThreadLocal pool. No synchronization, > >>>> little > >>>> to no > >>>> allocations. > >>> > >>> It also can cause massive memory leaks if invoked from threads > >>> which > >>> aren't re-used, like timer threads, and precautions aren't taken. > >>> AS/EAP > >>> 5 suffered from that problem with the default ThreadLocalPool. > >>> > >> > >> Which is also something that could be mitigated by a common thread > >> facility. Something AS/EAP 5 didn't have. > >> > >> Honestly though, I think this talk of EJB pooling is ridiculous. > >> Component layers like CDI and JAX-RS don't have pooled > >> architectures > >> for > >> their per-request objects. Also, in an average application, there > >> are > >> multiple orders of magnitude more non component classes that are > >> being > >> instantiated per request. Just think of all the Strings created > >> by a > >> simple HTTP request. > >> > >> You want a better focus? How about JSON/XML marshalling? Which > >> could > >> make things much easier to maintain then the hand-coded parsers > >> that > >> Wildfly uses to parse config. And much faster and less memory at > >> runtime for SOAP and JAX-RS request that currently rely on java > >> reflection. > >> > >> You could go research perfect hashing algorithms for URL matching > >> with > >> servlets and JAX-RS. > >> > >> You could go do some perf analysis of all of our frameworks to > >> make > >> memory reduction and speed recommendations or even Pull Requests. > >> > >> You could visit each major project and make sure our automated > >> builds > >> have and can run automated stress tests and are measured against > >> previous versions. > >> > >> Or you could just focus on these silly benchmarks that test no-op > >> HTTP > >> and EJB requests. > >> > > > > Those silly benchmarks, are indeed silly. Any workload that > > doesn't actually do anything with the requests is not very > > helpful. You can be really fast on them, and be really slow on a > > workload that actually does something. We have already seen this > > in one case recently. > > It?s all about precision, and limiting variables. I know its fun to > criticize micro benchmarks (obviously micro is indeed relative > because a great deal of processing goes on even when you have EJB > and HTTP requests that don?t do much), however micro benchmarks, > provided they are measured correctly, are quick to run and make it > easy to tell what you have to fix. Large gigantic apps on the other > hand are difficult to analyze, and do not necessarily represent > activity that a differently architected app would show. To use an > example, if you have pattern matching code, and you want it to be > fast, it?s much easier (and accurate) to benchmark the pattern > matching code then it is to benchmaark a full EE app that happens to > use pattern matching in a few places. > I know micro benchmarks can be useful, and the performance has actually written a couple ourselves. They have to be very carefully designed, so that the results transfer to larger complex workloads. > Arguing against targeted benchmarks is like arguing that you should > never write a test case, because only real production load will show > problems?. To some extent thats true, but that doesn?t mean that the > problems you catch in simulations won?t affect production users. > I don't argue against them, in principal, just that most of the ones I have seen haven't actually exposed problems we continue to find with our larger more complex workloads. Andy > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > From anmiller at redhat.com Tue Aug 5 15:54:22 2014 From: anmiller at redhat.com (Andrig Miller) Date: Tue, 5 Aug 2014 15:54:22 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E0FD09.1000605@redhat.com> References: <53CD3CCE.2030902@imixs.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> Message-ID: <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Bill Burke" > To: "Jason Greene" > Cc: "Andrig Miller" , wildfly-dev at lists.jboss.org > Sent: Tuesday, August 5, 2014 9:49:29 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > > On 8/5/2014 10:51 AM, Jason Greene wrote: > > > > On Aug 5, 2014, at 9:32 AM, Bill Burke wrote: > > > >> > >> > >> On 8/5/2014 10:15 AM, Jason Greene wrote: > >>>> Those silly benchmarks, are indeed silly. Any workload that > >>>> doesn't actually do anything with the requests is not very > >>>> helpful. You can be really fast on them, and be really slow on > >>>> a workload that actually does something. We have already seen > >>>> this in one case recently. > >>> > >>> It?s all about precision, and limiting variables. I know its fun > >>> to criticize micro benchmarks (obviously micro is indeed > >>> relative because a great deal of processing goes on even when > >>> you have EJB and HTTP requests that don?t do much), however > >>> micro benchmarks, provided they are measured correctly, are > >>> quick to run and make it easy to tell what you have to fix. > >>> Large gigantic apps on the other hand are difficult to analyze, > >>> and do not necessarily represent activity that a differently > >>> architected app would show. To use an example, if you have > >>> pattern matching code, and you want it to be fast, it?s much > >>> easier (and accurate) to benchmark the pattern matching code > >>> then it is to benchmaark a full EE app that happens to use > >>> pattern matching in a few places. > >>> > >>> Arguing against targeted benchmarks is like arguing that you > >>> should never write a test case, because only real production > >>> load will show problems?. To some extent thats true, but that > >>> doesn?t mean that the problems you catch in simulations won?t > >>> affect production users. > >>> > >> > >> I'm more worried about focus rather than the actual benchmarks > >> considering how resource strapped every project seems to be. I'd > >> like to see a discussion started on what are the most important > >> and *ripe* areas for optimization and then have the performance > >> team validate and make recommendations on any priority list that > >> this discussion generates. > > > > The pooling concerns (aside from the occasional expensive post > > constructs) actually came from a large app/benchmark that the perf > > team was testing, and they were seeing an optimized strict max > > pool outperform no pooling at all, and it wasn?t post construct. > > Their theory is/was GC pressure, because this benchmark/app spends > > a lot of time in GC, and they see higher GC activity with no > > pooling. It?s possible it could be an indirect difference though, > > like the fact that strict max pool acts as a throttle might > > prevent the system from degrading as a result of no longer being > > able to keep up with the benchmark load. > > > > Its a horrible theory. :) How many EJB instances of a give type are > created per request? Generally only 1. 1 instance of one object of > one > type! My $5 bet is that if you went into EJB code and started > counting > how many object allocations were made per request, you'd lose count > very > quickly. Better yet, run a single remote EJB request through a perf > tool and let it count the number of allocations for you. It will be > greater than 1. :) > > Maybe the StrictMaxPool has an effect on performance because it > creates > a global synchronization bottleneck. Throughput is less and you end > up > having less concurrent per-request objects being allocated and GC'd. > The number per request, while relevant is only part of the story. The number of concurrent requests happening in the server dictates the object allocation rate. Given enough concurrency, even a very small number of object allocations per request can create an object allocation rate that can no longer be sustained. Andy > > > Another possibility to look into is that I see we do: > > interceptorContext.setContextData(new HashMap > Object>()); > > > > *AND* > > > > private Map instanceData = new HashMap > Object>(); > > > > > > Aside from the unnecessary overhead, since JDK7, HashMap > > construction uses the murmur algorithm which requires using a > > random number generation under global locking. There were plans to > > optimize this, but it might not be in JDK7 yet. In a few places we > > use alternative map implementations to work around the issue. > > > > > > IMO, it is more likely that most projects haven't gone through the > level > of refactorings that performance-focused projects like Undertow have > gone through. I'll put another $5 bet down that only the Wildfly > family > of projects under you and DML have gone through any real performance > analysis and optimizations. Just think of all the crappiness that is > happening in the security layer alone! > > Also, any optimizations projects have done are probably focused on > speed > and throughput which generally is at the expense of memory. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stuart.w.douglas at gmail.com Tue Aug 5 18:03:10 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 06 Aug 2014 08:03:10 +1000 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E11D05.5020903@redhat.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> <53E105A2.4070902@jboss.com> <53E1117D.6020702@jboss.com> <53E117FF.5020704@redhat.com> <53E11BD9.70200@jboss.com> <53E11D05.5020903@redhat.com> Message-ID: <53E1549E.6070106@gmail.com> Brian Stansberry wrote: > TBH, I don't care much one way or the other. :) Using 'server' sucks; > changing names invariable comes back and bites you with tedious work > when you're least in the mood. So, choose your poison. If you prefer the > 'client' poison, that's ok with me. > > Wait for Stuart to have a chance to read this though as he's the poor > soul who's had to do the most work in this area. I am happy to change it to have the 'client' root element, although we need to maintain compatibility. It looks like current issues are mostly because I did this in a hurry and did not think it through. I think we should also just move this into core. It does feel a bit wrong because this is an EE thing, but I think it is the simplest solution. Stuart > > On 8/5/14, 1:00 PM, Darran Lofthouse wrote: >> On 05/08/14 18:44, Brian Stansberry wrote: >>> Just compatibility. Changing the "standard" element name means updating >>> docs, examples etc. >> Personally I think that is just something we have to accept we will have >> to do - at the moment we have a parser that follows a schema 'a bit' and >> I don't think docs and examples are a strong enough justification to >> keep it that way for WF9 and beyond. >> >>> We are going to have to parse legacy documents with 'server' no matter what. >> +1 which is why I am suggesting we fix it from version 3. >> >> >>> On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >>>> Just to split this into two decisions: - >>>> >>>> Is there any reason the root element needs to be 'server' even though >>>> the server definition differs depending on what is parsing it or should >>>> we add a new root element 'client'? >>>> >>>> On 05/08/14 17:26, Darran Lofthouse wrote: >>>>> >>>>> On 05/08/14 17:20, Brian Stansberry wrote: >>>>>> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >>>>>>> After forward porting some schema changes from EAP to WildFly it has >>>>>>> become apparent that it is a little cumbersome to work with AppClientXml >>>>>>> as it's implementation is dependent on the schema definitions in >>>>>>> wildfly-core and yet it lives in wildfly. >>>>>>> >>>>>>> The first point I realise is that the root element parsed by >>>>>>> AppClientXml is 'server' however it only accepts a subset of the >>>>>>> elements defined as supported by the 'server' element. Could it make >>>>>>> sense for version 3 of the schema and onward to have a new root element >>>>>>> 'client'? >>>>>>> >>>>>>> Secondly this could open up the option to have the client element >>>>>>> defined in a schema in wildfly and just reference the types that are in >>>>>>> wildfly-core. wildfly would then contain the parsing code for client >>>>>>> and the parsing code for the referenced types would be in wildfly-core >>>>>>> and accessed through an agreed API that we maintain for compatibility. >>>>>>> >>>>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>>>> core. I don't much like having core parsing stuff as part of the API >>>>>> exposed by core. >>>>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>>>> >>>>>> If we add an API it needs to be really coarse grained. >>>>> Yes I was thinking something corse grained to the level of: - >>>>> parseProfile() >>>>> parseSocketBindings() >>>>> >>>>> Each of these methods would then need to be responsible for their own >>>>> version check. >>>>> >>>>>> The only tie this class has to anything outside of core is one logger >>>>>> message that at a glance looks like something that probably already >>>>>> exists in core. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 bburke at redhat.com Tue Aug 5 18:36:11 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 Aug 2014 18:36:11 -0400 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> Message-ID: <53E15C5B.3040209@redhat.com> On 8/5/2014 3:54 PM, Andrig Miller wrote: >> Its a horrible theory. :) How many EJB instances of a give type are >> created per request? Generally only 1. 1 instance of one object of >> one >> type! My $5 bet is that if you went into EJB code and started >> counting >> how many object allocations were made per request, you'd lose count >> very >> quickly. Better yet, run a single remote EJB request through a perf >> tool and let it count the number of allocations for you. It will be >> greater than 1. :) >> >> Maybe the StrictMaxPool has an effect on performance because it >> creates >> a global synchronization bottleneck. Throughput is less and you end >> up >> having less concurrent per-request objects being allocated and GC'd. >> > > The number per request, while relevant is only part of the story. The number of concurrent requests happening in the server dictates the object allocation rate. Given enough concurrency, even a very small number of object allocations per request can create an object allocation rate that can no longer be sustained. > I'm saying that the number of concurrent requests might not dictate object allocation rate. There are probably a number of allocations that happen after the EJB instance is obtained. i.e. interception chains, contexts, etc. If StrictMaxPool blocks until a new instance is available, then there would be less allocations per request as blocking threads would be serialized. Whoever is investigating StrictMaxPool, or EJB pooling in general should stop. Its pointless. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From rodakr at gmx.ch Tue Aug 5 20:51:03 2014 From: rodakr at gmx.ch (Radoslaw Rodak) Date: Wed, 6 Aug 2014 02:51:03 +0200 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E15C5B.3040209@redhat.com> References: <53CD3CCE.2030902@imixs.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> Message-ID: Am 06.08.2014 um 00:36 schrieb Bill Burke : > > > On 8/5/2014 3:54 PM, Andrig Miller wrote: >>> Its a horrible theory. :) How many EJB instances of a give type are >>> created per request? Generally only 1. 1 instance of one object of >>> one >>> type! My $5 bet is that if you went into EJB code and started >>> counting >>> how many object allocations were made per request, you'd lose count >>> very >>> quickly. Better yet, run a single remote EJB request through a perf >>> tool and let it count the number of allocations for you. It will be >>> greater than 1. :) >>> >>> Maybe the StrictMaxPool has an effect on performance because it >>> creates >>> a global synchronization bottleneck. Throughput is less and you end >>> up >>> having less concurrent per-request objects being allocated and GC'd. >>> >> >> The number per request, while relevant is only part of the story. The number of concurrent requests happening in the server dictates the object allocation rate. Given enough concurrency, even a very small number of object allocations per request can create an object allocation rate that can no longer be sustained. >> > > I'm saying that the number of concurrent requests might not dictate > object allocation rate. There are probably a number of allocations that > happen after the EJB instance is obtained. i.e. interception chains, > contexts, etc. If StrictMaxPool blocks until a new instance is > available, then there would be less allocations per request as blocking > threads would be serialized. > Scenarion 1 ) ------------------ Let say we have a pool of 100 Stateless EJBs and a constant Load of 50 Requests per second proceeded by 50 EJBs from the pool in one second. After 1000 seconds how many new EJB Instances will be created having a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course object allocation is much higher as of course 1 EJB call leads to many Object from one EJB but?let see situation without pool. 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on Java heap where 1 EJB might have many objects? as long as Garbage Collection was not triggered? which sounds to me like faster filling JVM heap and having ofter GC probable depending on GC Strategy. Scenarion 2) ------------------ Same as before, Load is still 50 Requests per second BUT EJB Method call takes 10s. after 10s we have 500 EJB Instances without pool, after 11s 550 - 10 = 540EJB Instances , after 12s 580 EJBs ? after some time very bad perf?full GC ?and mabe OutOfMemory.. So? performance advantage could also turn in to disadvantage :-) > Whoever is investigating StrictMaxPool, or EJB pooling in general should > stop. Its pointless. Agree, pools are outdated?. but something like WorkManager for min, max Threads or even better always not less the X idle Threads would be useful :-) Radek From hbraun at redhat.com Wed Aug 6 03:36:49 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 6 Aug 2014 09:36:49 +0200 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> Message-ID: <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> +1 On 05 Aug 2014, at 16:20, Kabir Khan wrote: > To me ?singleton? sounds the best so far -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140806/16036190/attachment.html From darran.lofthouse at jboss.com Wed Aug 6 07:30:19 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 06 Aug 2014 12:30:19 +0100 Subject: [wildfly-dev] AppClientXml - Post Code Split In-Reply-To: <53E1549E.6070106@gmail.com> References: <53E10129.10406@jboss.com> <53E10464.8000808@redhat.com> <53E105A2.4070902@jboss.com> <53E1117D.6020702@jboss.com> <53E117FF.5020704@redhat.com> <53E11BD9.70200@jboss.com> <53E11D05.5020903@redhat.com> <53E1549E.6070106@gmail.com> Message-ID: <53E211CB.8010307@jboss.com> For previous versions of the schema we are just going to have to stick with supporting parsing of 'server', for version 3 I think it will be easier to add a clean parser that starts parsing at 'client'. We probably don't need to move the whole of app client to core but as a bare minimum if we moved all the parsing to core it will mean that is the only place we need to worry about updates to the as schema. Although this is where the option to split out the 'client' root element definition into it's own schema although complexity wise it is probably not worth it. The concept of a client configuration is probably generic enough to be in core even though our motivations for using it are on the back of EE. Regards, Darran Lofthouse. On 05/08/14 23:03, Stuart Douglas wrote: > > > Brian Stansberry wrote: >> TBH, I don't care much one way or the other. :) Using 'server' sucks; >> changing names invariable comes back and bites you with tedious work >> when you're least in the mood. So, choose your poison. If you prefer the >> 'client' poison, that's ok with me. >> >> Wait for Stuart to have a chance to read this though as he's the poor >> soul who's had to do the most work in this area. > > I am happy to change it to have the 'client' root element, although we > need to maintain compatibility. It looks like current issues are mostly > because I did this in a hurry and did not think it through. > > I think we should also just move this into core. It does feel a bit > wrong because this is an EE thing, but I think it is the simplest solution. > > Stuart > > >> >> On 8/5/14, 1:00 PM, Darran Lofthouse wrote: >>> On 05/08/14 18:44, Brian Stansberry wrote: >>>> Just compatibility. Changing the "standard" element name means updating >>>> docs, examples etc. >>> Personally I think that is just something we have to accept we will have >>> to do - at the moment we have a parser that follows a schema 'a bit' and >>> I don't think docs and examples are a strong enough justification to >>> keep it that way for WF9 and beyond. >>> >>>> We are going to have to parse legacy documents with 'server' no matter what. >>> +1 which is why I am suggesting we fix it from version 3. >>> >>> >>>> On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >>>>> Just to split this into two decisions: - >>>>> >>>>> Is there any reason the root element needs to be 'server' even though >>>>> the server definition differs depending on what is parsing it or should >>>>> we add a new root element 'client'? >>>>> >>>>> On 05/08/14 17:26, Darran Lofthouse wrote: >>>>>> >>>>>> On 05/08/14 17:20, Brian Stansberry wrote: >>>>>>> On 8/5/14, 11:07 AM, Darran Lofthouse wrote: >>>>>>>> After forward porting some schema changes from EAP to WildFly it has >>>>>>>> become apparent that it is a little cumbersome to work with AppClientXml >>>>>>>> as it's implementation is dependent on the schema definitions in >>>>>>>> wildfly-core and yet it lives in wildfly. >>>>>>>> >>>>>>>> The first point I realise is that the root element parsed by >>>>>>>> AppClientXml is 'server' however it only accepts a subset of the >>>>>>>> elements defined as supported by the 'server' element. Could it make >>>>>>>> sense for version 3 of the schema and onward to have a new root element >>>>>>>> 'client'? >>>>>>>> >>>>>>>> Secondly this could open up the option to have the client element >>>>>>>> defined in a schema in wildfly and just reference the types that are in >>>>>>>> wildfly-core. wildfly would then contain the parsing code for client >>>>>>>> and the parsing code for the referenced types would be in wildfly-core >>>>>>>> and accessed through an agreed API that we maintain for compatibility. >>>>>>>> >>>>>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>>>>> core. I don't much like having core parsing stuff as part of the API >>>>>>> exposed by core. >>>>>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>>>>> >>>>>>> If we add an API it needs to be really coarse grained. >>>>>> Yes I was thinking something corse grained to the level of: - >>>>>> parseProfile() >>>>>> parseSocketBindings() >>>>>> >>>>>> Each of these methods would then need to be responsible for their own >>>>>> version check. >>>>>> >>>>>>> The only tie this class has to anything outside of core is one logger >>>>>>> message that at a glance looks like something that probably already >>>>>>> exists in core. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From anmiller at redhat.com Wed Aug 6 10:47:53 2014 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 6 Aug 2014 10:47:53 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E15C5B.3040209@redhat.com> References: <53CD3CCE.2030902@imixs.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> Message-ID: <25320436.672.1407336470565.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Bill Burke" > To: "Andrig Miller" > Cc: wildfly-dev at lists.jboss.org, "Jason Greene" > Sent: Tuesday, August 5, 2014 4:36:11 PM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > > On 8/5/2014 3:54 PM, Andrig Miller wrote: > >> Its a horrible theory. :) How many EJB instances of a give type > >> are > >> created per request? Generally only 1. 1 instance of one object > >> of > >> one > >> type! My $5 bet is that if you went into EJB code and started > >> counting > >> how many object allocations were made per request, you'd lose > >> count > >> very > >> quickly. Better yet, run a single remote EJB request through a > >> perf > >> tool and let it count the number of allocations for you. It will > >> be > >> greater than 1. :) > >> > >> Maybe the StrictMaxPool has an effect on performance because it > >> creates > >> a global synchronization bottleneck. Throughput is less and you > >> end > >> up > >> having less concurrent per-request objects being allocated and > >> GC'd. > >> > > > > The number per request, while relevant is only part of the story. > > The number of concurrent requests happening in the server > > dictates the object allocation rate. Given enough concurrency, > > even a very small number of object allocations per request can > > create an object allocation rate that can no longer be sustained. > > > > I'm saying that the number of concurrent requests might not dictate > object allocation rate. There are probably a number of allocations > that > happen after the EJB instance is obtained. i.e. interception chains, > contexts, etc. If StrictMaxPool blocks until a new instance is > available, then there would be less allocations per request as > blocking > threads would be serialized. > > Whoever is investigating StrictMaxPool, or EJB pooling in general > should > stop. Its pointless. > Ah, no its not pointless. We have a new non-blocking implementation of StrictMaxPool, and its upstream in Wildfly 9, and will be in EAP 6.4. It has helped us increase our throughput, and reduce response times alot! Andy > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From anmiller at redhat.com Wed Aug 6 10:50:13 2014 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 6 Aug 2014 10:50:13 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: References: <53CD3CCE.2030902@imixs.com> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> Message-ID: <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Radoslaw Rodak" > To: wildfly-dev at lists.jboss.org > Sent: Tuesday, August 5, 2014 6:51:03 PM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > Am 06.08.2014 um 00:36 schrieb Bill Burke : > > > > > > > On 8/5/2014 3:54 PM, Andrig Miller wrote: > >>> Its a horrible theory. :) How many EJB instances of a give type > >>> are > >>> created per request? Generally only 1. 1 instance of one object > >>> of > >>> one > >>> type! My $5 bet is that if you went into EJB code and started > >>> counting > >>> how many object allocations were made per request, you'd lose > >>> count > >>> very > >>> quickly. Better yet, run a single remote EJB request through a > >>> perf > >>> tool and let it count the number of allocations for you. It will > >>> be > >>> greater than 1. :) > >>> > >>> Maybe the StrictMaxPool has an effect on performance because it > >>> creates > >>> a global synchronization bottleneck. Throughput is less and you > >>> end > >>> up > >>> having less concurrent per-request objects being allocated and > >>> GC'd. > >>> > >> > >> The number per request, while relevant is only part of the story. > >> The number of concurrent requests happening in the server > >> dictates the object allocation rate. Given enough concurrency, > >> even a very small number of object allocations per request can > >> create an object allocation rate that can no longer be sustained. > >> > > > > I'm saying that the number of concurrent requests might not dictate > > object allocation rate. There are probably a number of allocations > > that > > happen after the EJB instance is obtained. i.e. interception > > chains, > > contexts, etc. If StrictMaxPool blocks until a new instance is > > available, then there would be less allocations per request as > > blocking > > threads would be serialized. > > > > Scenarion 1 ) > ------------------ > Let say we have a pool of 100 Stateless EJBs and a constant Load of > 50 Requests per second proceeded by 50 EJBs from the pool in one > second. > After 1000 seconds how many new EJB Instances will be created having > a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course > object allocation is much higher as of course 1 EJB call leads to > many Object from one EJB but?let see situation without pool. > > 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on > Java heap where 1 EJB might have many objects? as long as Garbage > Collection was not triggered? which sounds to me like faster filling > JVM heap and having ofter GC probable depending on GC Strategy. > > Scenarion 2) > ------------------ > Same as before, Load is still 50 Requests per second BUT EJB Method > call takes 10s. > after 10s we have 500 EJB Instances without pool, after 11s 550 - 10 > = 540EJB Instances , after 12s 580 EJBs ? after some time very bad > perf?full GC ?and mabe OutOfMemory.. > > So? performance advantage could also turn in to disadvantage :-) > > > > Whoever is investigating StrictMaxPool, or EJB pooling in general > > should > > stop. Its pointless. > > Agree, pools are outdated?. but something like WorkManager for min, > max Threads or even better always not less the X idle Threads would > be useful :-) > > Radek > The scenarios above are what is outddated. Fifty requests per second isn't any load at all! We have 100's of thousands of clients that we have to scale to, and lots more than 50 requests per second. Andy > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Wed Aug 6 11:13:58 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 6 Aug 2014 10:13:58 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: References: <53CD3CCE.2030902@imixs.com> <1407199492.8921.21.camel@dhcp-0-235.bne.redhat.com> <53E0DCD4.8000406@redhat.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> Message-ID: On Aug 5, 2014, at 7:51 PM, Radoslaw Rodak wrote: > > Am 06.08.2014 um 00:36 schrieb Bill Burke : > >> >> >> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>> Its a horrible theory. :) How many EJB instances of a give type are >>>> created per request? Generally only 1. 1 instance of one object of >>>> one >>>> type! My $5 bet is that if you went into EJB code and started >>>> counting >>>> how many object allocations were made per request, you'd lose count >>>> very >>>> quickly. Better yet, run a single remote EJB request through a perf >>>> tool and let it count the number of allocations for you. It will be >>>> greater than 1. :) >>>> >>>> Maybe the StrictMaxPool has an effect on performance because it >>>> creates >>>> a global synchronization bottleneck. Throughput is less and you end >>>> up >>>> having less concurrent per-request objects being allocated and GC'd. >>>> >>> >>> The number per request, while relevant is only part of the story. The number of concurrent requests happening in the server dictates the object allocation rate. Given enough concurrency, even a very small number of object allocations per request can create an object allocation rate that can no longer be sustained. >>> >> >> I'm saying that the number of concurrent requests might not dictate >> object allocation rate. There are probably a number of allocations that >> happen after the EJB instance is obtained. i.e. interception chains, >> contexts, etc. If StrictMaxPool blocks until a new instance is >> available, then there would be less allocations per request as blocking >> threads would be serialized. >> > > Scenarion 1 ) > ------------------ > Let say we have a pool of 100 Stateless EJBs and a constant Load of 50 Requests per second proceeded by 50 EJBs from the pool in one second. > After 1000 seconds how many new EJB Instances will be created having a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course object allocation is much higher as of course 1 EJB call leads to many Object from one EJB but?let see situation without pool. > > 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on Java heap where 1 EJB might have many objects? as long as Garbage Collection was not triggered? which sounds to me like faster filling JVM heap and having ofter GC probable depending on GC Strategy. If you think about a single Java EE request invocation that processes data with one EJB in the call, there is typically hundreds of temporary objects created (perhaps even thousands when you are pulling back many rows of data from JPA). Aside from the container API requirements (the container has to create a string for every http header name and value, which can easily be 20+ objects), just writing plain java code that does things like substring creates temporary objects. Now, I don?t have an exact object instance count for an SLSB creation, but glancing at the code it looks ~ 6 objects. So we are talking about a very small percentage of object space, probably around 1-2%. On the other hand the percentage could be high if you have an ejb method that doesn?t do much (e.g. just returns a constant) and you call it in a big loop as part of a request. Then you could get 6 * N object churn, which could very well end up to be a high percentage (for a large enough value of N). -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From johara at redhat.com Wed Aug 6 11:18:23 2014 From: johara at redhat.com (John O'Hara) Date: Wed, 06 Aug 2014 16:18:23 +0100 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <25320436.672.1407336470565.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <25320436.672.1407336470565.JavaMail.andrig@worklaptop.miller.org> Message-ID: <53E2473F.6070108@redhat.com> On 08/06/2014 03:47 PM, Andrig Miller wrote: > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Andrig Miller" >> Cc: wildfly-dev at lists.jboss.org, "Jason Greene" >> Sent: Tuesday, August 5, 2014 4:36:11 PM >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >> >> >> >> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>> Its a horrible theory. :) How many EJB instances of a give type >>>> are >>>> created per request? Generally only 1. 1 instance of one object >>>> of >>>> one >>>> type! My $5 bet is that if you went into EJB code and started >>>> counting >>>> how many object allocations were made per request, you'd lose >>>> count >>>> very >>>> quickly. Better yet, run a single remote EJB request through a >>>> perf >>>> tool and let it count the number of allocations for you. It will >>>> be >>>> greater than 1. :) >>>> >>>> Maybe the StrictMaxPool has an effect on performance because it >>>> creates >>>> a global synchronization bottleneck. Throughput is less and you >>>> end >>>> up >>>> having less concurrent per-request objects being allocated and >>>> GC'd. >>>> >>> The number per request, while relevant is only part of the story. >>> The number of concurrent requests happening in the server >>> dictates the object allocation rate. Given enough concurrency, >>> even a very small number of object allocations per request can >>> create an object allocation rate that can no longer be sustained. >>> >> I'm saying that the number of concurrent requests might not dictate >> object allocation rate. There are probably a number of allocations >> that >> happen after the EJB instance is obtained. i.e. interception chains, >> contexts, etc. If StrictMaxPool blocks until a new instance is >> available, then there would be less allocations per request as >> blocking >> threads would be serialized. >> >> Whoever is investigating StrictMaxPool, or EJB pooling in general >> should >> stop. Its pointless. >> > Ah, no its not pointless. We have a new non-blocking implementation of StrictMaxPool, and its upstream in Wildfly 9, and will be in EAP 6.4. It has helped us increase our throughput, and reduce response times alot! > > Andy Some contextual numbers around what Andy is describing. These are results from one of our benchmarks; * * *Average response times (28600 concurrent users)* *Pooled* *Non-pooled* Remote EJB invocations 0.114s 2.094s WS invocations 0.105s 0.332s HTTP web app invocations HttpCallTypeA 0.090s 5.589s HttpCallTypeB 0.042s 2.510s HttpCallTypeC 0.116s 7.267S The only difference between these two sets of numbers is EJB pooling. > >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- John O'Hara johara at redhat.com JBoss, by Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140806/81429506/attachment-0001.html From bburke at redhat.com Wed Aug 6 11:30:06 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 06 Aug 2014 11:30:06 -0400 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> Message-ID: <53E249FE.2010704@redhat.com> On 8/6/2014 10:50 AM, Andrig Miller wrote: > > > ----- Original Message ----- >> From: "Radoslaw Rodak" >> To: wildfly-dev at lists.jboss.org >> Sent: Tuesday, August 5, 2014 6:51:03 PM >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >> >> >> Am 06.08.2014 um 00:36 schrieb Bill Burke : >> >>> >>> >>> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>>> Its a horrible theory. :) How many EJB instances of a give type >>>>> are >>>>> created per request? Generally only 1. 1 instance of one object >>>>> of >>>>> one >>>>> type! My $5 bet is that if you went into EJB code and started >>>>> counting >>>>> how many object allocations were made per request, you'd lose >>>>> count >>>>> very >>>>> quickly. Better yet, run a single remote EJB request through a >>>>> perf >>>>> tool and let it count the number of allocations for you. It will >>>>> be >>>>> greater than 1. :) >>>>> >>>>> Maybe the StrictMaxPool has an effect on performance because it >>>>> creates >>>>> a global synchronization bottleneck. Throughput is less and you >>>>> end >>>>> up >>>>> having less concurrent per-request objects being allocated and >>>>> GC'd. >>>>> >>>> >>>> The number per request, while relevant is only part of the story. >>>> The number of concurrent requests happening in the server >>>> dictates the object allocation rate. Given enough concurrency, >>>> even a very small number of object allocations per request can >>>> create an object allocation rate that can no longer be sustained. >>>> >>> >>> I'm saying that the number of concurrent requests might not dictate >>> object allocation rate. There are probably a number of allocations >>> that >>> happen after the EJB instance is obtained. i.e. interception >>> chains, >>> contexts, etc. If StrictMaxPool blocks until a new instance is >>> available, then there would be less allocations per request as >>> blocking >>> threads would be serialized. >>> >> >> Scenarion 1 ) >> ------------------ >> Let say we have a pool of 100 Stateless EJBs and a constant Load of >> 50 Requests per second proceeded by 50 EJBs from the pool in one >> second. >> After 1000 seconds how many new EJB Instances will be created having >> a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course >> object allocation is much higher as of course 1 EJB call leads to >> many Object from one EJB but?let see situation without pool. >> >> 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on >> Java heap where 1 EJB might have many objects? as long as Garbage >> Collection was not triggered? which sounds to me like faster filling >> JVM heap and having ofter GC probable depending on GC Strategy. >> >> Scenarion 2) >> ------------------ >> Same as before, Load is still 50 Requests per second BUT EJB Method >> call takes 10s. >> after 10s we have 500 EJB Instances without pool, after 11s 550 - 10 >> = 540EJB Instances , after 12s 580 EJBs ? after some time very bad >> perf?full GC ?and mabe OutOfMemory.. >> >> So? performance advantage could also turn in to disadvantage :-) >> >> >>> Whoever is investigating StrictMaxPool, or EJB pooling in general >>> should >>> stop. Its pointless. >> >> Agree, pools are outdated?. but something like WorkManager for min, >> max Threads or even better always not less the X idle Threads would >> be useful :-) >> >> Radek >> > > The scenarios above are what is outddated. Fifty requests per second isn't any load at all! We have 100's of thousands of clients that we have to scale to, and lots more than 50 requests per second. > What you mean to say is that you need to scale to 100's of thousands of clients on meaningless no-op benchmarks. :) I do know that that old SpecJ Java EE benchmarks artifically made EJB pooling important as process intensive calculation results were cached in these instances. But real-world apps don't use this feature/anti-pattern. Also however crappy it was, I did implement an EJB container at one time in my career. :) I know for a fact that there are a number of per-request internal support objects that need to be allocated. Let's count: * The argument array (for reflection) * Each argument of the method call * The response object * Interceptor context object * The interceptor context attribute map * EJBContext * Subject, Principal, role mappings * Transaction context * The message object(s) specific to the remote EJB protocol Starts to add up huh? I'm probably missing a bunch more. Throw in interaction with JPA and you end up with even more per-request objects being allocated. You still believe pooling one EJB instance matters? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jason.greene at redhat.com Wed Aug 6 11:43:11 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 6 Aug 2014 10:43:11 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E2473F.6070108@redhat.com> References: <53CD3CCE.2030902@imixs.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <25320436.672.1407336470565.JavaMail.andrig@worklaptop.miller.org> <53E2473F.6070108@redhat.com> Message-ID: On Aug 6, 2014, at 10:18 AM, John O'Hara wrote: > On 08/06/2014 03:47 PM, Andrig Miller wrote: >> >> ----- Original Message ----- >> >>> From: "Bill Burke" >>> >>> To: "Andrig Miller" >>> >>> >>> Cc: >>> wildfly-dev at lists.jboss.org, "Jason Greene" >>> >>> Sent: Tuesday, August 5, 2014 4:36:11 PM >>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>> >>> >>> >>> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>> >>>>> Its a horrible theory. :) How many EJB instances of a give type >>>>> are >>>>> created per request? Generally only 1. 1 instance of one object >>>>> of >>>>> one >>>>> type! My $5 bet is that if you went into EJB code and started >>>>> counting >>>>> how many object allocations were made per request, you'd lose >>>>> count >>>>> very >>>>> quickly. Better yet, run a single remote EJB request through a >>>>> perf >>>>> tool and let it count the number of allocations for you. It will >>>>> be >>>>> greater than 1. :) >>>>> >>>>> Maybe the StrictMaxPool has an effect on performance because it >>>>> creates >>>>> a global synchronization bottleneck. Throughput is less and you >>>>> end >>>>> up >>>>> having less concurrent per-request objects being allocated and >>>>> GC'd. >>>>> >>>>> >>>> The number per request, while relevant is only part of the story. >>>> The number of concurrent requests happening in the server >>>> dictates the object allocation rate. Given enough concurrency, >>>> even a very small number of object allocations per request can >>>> create an object allocation rate that can no longer be sustained. >>>> >>>> >>> I'm saying that the number of concurrent requests might not dictate >>> object allocation rate. There are probably a number of allocations >>> that >>> happen after the EJB instance is obtained. i.e. interception chains, >>> contexts, etc. If StrictMaxPool blocks until a new instance is >>> available, then there would be less allocations per request as >>> blocking >>> threads would be serialized. >>> >>> Whoever is investigating StrictMaxPool, or EJB pooling in general >>> should >>> stop. Its pointless. >>> >>> >> Ah, no its not pointless. We have a new non-blocking implementation of StrictMaxPool, and its upstream in Wildfly 9, and will be in EAP 6.4. It has helped us increase our throughput, and reduce response times alot! >> >> Andy >> > Some contextual numbers around what Andy is describing. These are results from one of our benchmarks; > > Average response times (28600 concurrent users) > Pooled > Non-pooled > Remote EJB invocations > 0.114s 2.094s > WS invocations > 0.105s 0.332s > HTTP web app invocations > > > HttpCallTypeA > 0.090s 5.589s > HttpCallTypeB 0.042s 2.510s > HttpCallTypeC 0.116s 7.267S I love data, thanks :) Have you by chance taken object histogram samples for these two? It would be useful to see how strong the correlation is, and if a use-pattern shows up in the benchmark that leads to a non-pool implementation creating massive amounts of objects (like the loop scenario I mentioned) -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From anmiller at redhat.com Wed Aug 6 11:49:08 2014 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 6 Aug 2014 11:49:08 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E249FE.2010704@redhat.com> References: <53CD3CCE.2030902@imixs.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> Message-ID: <24380467.708.1407340144909.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Bill Burke" > To: wildfly-dev at lists.jboss.org > Sent: Wednesday, August 6, 2014 9:30:06 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > > On 8/6/2014 10:50 AM, Andrig Miller wrote: > > > > > > ----- Original Message ----- > >> From: "Radoslaw Rodak" > >> To: wildfly-dev at lists.jboss.org > >> Sent: Tuesday, August 5, 2014 6:51:03 PM > >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > >> > >> > >> Am 06.08.2014 um 00:36 schrieb Bill Burke : > >> > >>> > >>> > >>> On 8/5/2014 3:54 PM, Andrig Miller wrote: > >>>>> Its a horrible theory. :) How many EJB instances of a give > >>>>> type > >>>>> are > >>>>> created per request? Generally only 1. 1 instance of one > >>>>> object > >>>>> of > >>>>> one > >>>>> type! My $5 bet is that if you went into EJB code and started > >>>>> counting > >>>>> how many object allocations were made per request, you'd lose > >>>>> count > >>>>> very > >>>>> quickly. Better yet, run a single remote EJB request through > >>>>> a > >>>>> perf > >>>>> tool and let it count the number of allocations for you. It > >>>>> will > >>>>> be > >>>>> greater than 1. :) > >>>>> > >>>>> Maybe the StrictMaxPool has an effect on performance because it > >>>>> creates > >>>>> a global synchronization bottleneck. Throughput is less and > >>>>> you > >>>>> end > >>>>> up > >>>>> having less concurrent per-request objects being allocated and > >>>>> GC'd. > >>>>> > >>>> > >>>> The number per request, while relevant is only part of the > >>>> story. > >>>> The number of concurrent requests happening in the server > >>>> dictates the object allocation rate. Given enough concurrency, > >>>> even a very small number of object allocations per request can > >>>> create an object allocation rate that can no longer be > >>>> sustained. > >>>> > >>> > >>> I'm saying that the number of concurrent requests might not > >>> dictate > >>> object allocation rate. There are probably a number of > >>> allocations > >>> that > >>> happen after the EJB instance is obtained. i.e. interception > >>> chains, > >>> contexts, etc. If StrictMaxPool blocks until a new instance is > >>> available, then there would be less allocations per request as > >>> blocking > >>> threads would be serialized. > >>> > >> > >> Scenarion 1 ) > >> ------------------ > >> Let say we have a pool of 100 Stateless EJBs and a constant Load > >> of > >> 50 Requests per second proceeded by 50 EJBs from the pool in > >> one > >> second. > >> After 1000 seconds how many new EJB Instances will be created > >> having > >> a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course > >> object allocation is much higher as of course 1 EJB call leads to > >> many Object from one EJB but?let see situation without pool. > >> > >> 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on > >> Java heap where 1 EJB might have many objects? as long as > >> Garbage > >> Collection was not triggered? which sounds to me like faster > >> filling > >> JVM heap and having ofter GC probable depending on GC Strategy. > >> > >> Scenarion 2) > >> ------------------ > >> Same as before, Load is still 50 Requests per second BUT EJB > >> Method > >> call takes 10s. > >> after 10s we have 500 EJB Instances without pool, after 11s 550 - > >> 10 > >> = 540EJB Instances , after 12s 580 EJBs ? after some time very > >> bad > >> perf?full GC ?and mabe OutOfMemory.. > >> > >> So? performance advantage could also turn in to disadvantage :-) > >> > >> > >>> Whoever is investigating StrictMaxPool, or EJB pooling in general > >>> should > >>> stop. Its pointless. > >> > >> Agree, pools are outdated?. but something like WorkManager for > >> min, > >> max Threads or even better always not less the X idle Threads > >> would > >> be useful :-) > >> > >> Radek > >> > > > > The scenarios above are what is outddated. Fifty requests per > > second isn't any load at all! We have 100's of thousands of > > clients that we have to scale to, and lots more than 50 requests > > per second. > > > What you mean to say is that you need to scale to 100's of thousands > of > clients on meaningless no-op benchmarks. :) I do know that that old > SpecJ Java EE benchmarks artifically made EJB pooling important as > process intensive calculation results were cached in these instances. > But real-world apps don't use this feature/anti-pattern. > I am not talking about a meaningless no-op benchmark, but a benchmark that does lots of work. We don't use meaningless no-op benchmarks on the performance team, with some exception for microbenchmarks that we have carefully crafted that model the interactions for a specific component within the context of how it is actually used for a real application. > Also however crappy it was, I did implement an EJB container at one > time > in my career. :) I know for a fact that there are a number of > per-request internal support objects that need to be allocated. > Let's > count: > > * The argument array (for reflection) > * Each argument of the method call > * The response object > * Interceptor context object > * The interceptor context attribute map > * EJBContext > * Subject, Principal, role mappings > * Transaction context > * The message object(s) specific to the remote EJB protocol > > Starts to add up huh? I'm probably missing a bunch more. Throw in > interaction with JPA and you end up with even more per-request > objects > being allocated. You still believe pooling one EJB instance matters? > See John O'Hara's post which shows our non-meaningless benchmark and the difference that pooling makes vs. non-pooling. It is a dramatic difference to say the least. This conversation is a perfect example of misinformation that causes us performance and scalability problems within our code bases. Andy > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Wed Aug 6 13:08:02 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 6 Aug 2014 12:08:02 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <24380467.708.1407340144909.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> <24380467.708.1407340144909.JavaMail.andrig@worklaptop.miller.org> Message-ID: <08F39457-CF7D-4F6F-9343-2251F0EB2562@redhat.com> On Aug 6, 2014, at 10:49 AM, Andrig Miller wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: wildfly-dev at lists.jboss.org >> Sent: Wednesday, August 6, 2014 9:30:06 AM >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >> >> >> >> On 8/6/2014 10:50 AM, Andrig Miller wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Radoslaw Rodak" >>>> To: wildfly-dev at lists.jboss.org >>>> Sent: Tuesday, August 5, 2014 6:51:03 PM >>>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>>> >>>> >>>> Am 06.08.2014 um 00:36 schrieb Bill Burke : >>>> >>>>> >>>>> >>>>> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>>>>> Its a horrible theory. :) How many EJB instances of a give >>>>>>> type >>>>>>> are >>>>>>> created per request? Generally only 1. 1 instance of one >>>>>>> object >>>>>>> of >>>>>>> one >>>>>>> type! My $5 bet is that if you went into EJB code and started >>>>>>> counting >>>>>>> how many object allocations were made per request, you'd lose >>>>>>> count >>>>>>> very >>>>>>> quickly. Better yet, run a single remote EJB request through >>>>>>> a >>>>>>> perf >>>>>>> tool and let it count the number of allocations for you. It >>>>>>> will >>>>>>> be >>>>>>> greater than 1. :) >>>>>>> >>>>>>> Maybe the StrictMaxPool has an effect on performance because it >>>>>>> creates >>>>>>> a global synchronization bottleneck. Throughput is less and >>>>>>> you >>>>>>> end >>>>>>> up >>>>>>> having less concurrent per-request objects being allocated and >>>>>>> GC'd. >>>>>>> >>>>>> >>>>>> The number per request, while relevant is only part of the >>>>>> story. >>>>>> The number of concurrent requests happening in the server >>>>>> dictates the object allocation rate. Given enough concurrency, >>>>>> even a very small number of object allocations per request can >>>>>> create an object allocation rate that can no longer be >>>>>> sustained. >>>>>> >>>>> >>>>> I'm saying that the number of concurrent requests might not >>>>> dictate >>>>> object allocation rate. There are probably a number of >>>>> allocations >>>>> that >>>>> happen after the EJB instance is obtained. i.e. interception >>>>> chains, >>>>> contexts, etc. If StrictMaxPool blocks until a new instance is >>>>> available, then there would be less allocations per request as >>>>> blocking >>>>> threads would be serialized. >>>>> >>>> >>>> Scenarion 1 ) >>>> ------------------ >>>> Let say we have a pool of 100 Stateless EJBs and a constant Load >>>> of >>>> 50 Requests per second proceeded by 50 EJBs from the pool in >>>> one >>>> second. >>>> After 1000 seconds how many new EJB Instances will be created >>>> having >>>> a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course >>>> object allocation is much higher as of course 1 EJB call leads to >>>> many Object from one EJB but?let see situation without pool. >>>> >>>> 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on >>>> Java heap where 1 EJB might have many objects? as long as >>>> Garbage >>>> Collection was not triggered? which sounds to me like faster >>>> filling >>>> JVM heap and having ofter GC probable depending on GC Strategy. >>>> >>>> Scenarion 2) >>>> ------------------ >>>> Same as before, Load is still 50 Requests per second BUT EJB >>>> Method >>>> call takes 10s. >>>> after 10s we have 500 EJB Instances without pool, after 11s 550 - >>>> 10 >>>> = 540EJB Instances , after 12s 580 EJBs ? after some time very >>>> bad >>>> perf?full GC ?and mabe OutOfMemory.. >>>> >>>> So? performance advantage could also turn in to disadvantage :-) >>>> >>>> >>>>> Whoever is investigating StrictMaxPool, or EJB pooling in general >>>>> should >>>>> stop. Its pointless. >>>> >>>> Agree, pools are outdated?. but something like WorkManager for >>>> min, >>>> max Threads or even better always not less the X idle Threads >>>> would >>>> be useful :-) >>>> >>>> Radek >>>> >>> >>> The scenarios above are what is outddated. Fifty requests per >>> second isn't any load at all! We have 100's of thousands of >>> clients that we have to scale to, and lots more than 50 requests >>> per second. >>> >> What you mean to say is that you need to scale to 100's of thousands >> of >> clients on meaningless no-op benchmarks. :) I do know that that old >> SpecJ Java EE benchmarks artifically made EJB pooling important as >> process intensive calculation results were cached in these instances. >> But real-world apps don't use this feature/anti-pattern. >> > > I am not talking about a meaningless no-op benchmark, but a benchmark that does lots of work. We don't use meaningless no-op benchmarks on the performance team, with some exception for microbenchmarks that we have carefully crafted that model the interactions for a specific component within the context of how it is actually used for a real application. > >> Also however crappy it was, I did implement an EJB container at one >> time >> in my career. :) I know for a fact that there are a number of >> per-request internal support objects that need to be allocated. >> Let's >> count: >> >> * The argument array (for reflection) >> * Each argument of the method call >> * The response object >> * Interceptor context object >> * The interceptor context attribute map >> * EJBContext >> * Subject, Principal, role mappings >> * Transaction context >> * The message object(s) specific to the remote EJB protocol >> >> Starts to add up huh? I'm probably missing a bunch more. Throw in >> interaction with JPA and you end up with even more per-request >> objects >> being allocated. You still believe pooling one EJB instance matters? >> > > See John O'Hara's post which shows our non-meaningless benchmark and the difference that pooling makes vs. non-pooling. It is a dramatic difference to say the least. There is certainly a correlation identified between the results of this benchmark and the use of pooling. However the underlying cause of the resulting difference is still unknown. If we knew definitively how and why this happens it would help in optimizing this further. As an example, if it turned out to be some secondary factor, like the throttling aspect of the pool, then eliminating these allocations (and others) with a zero-tuning approach, like thread local pooling would offer little to no improvement. If discovered it is indeed extreme object allocation, and that it came from thousands of nested calls in a request, then having a temporary per-request thread local cache would dramatically improve the results, and be cheap/quick to implement vs a full thread local solution. If there is a bug in our code somewhere where under certain situations we create hundreds of objects, when we should be creating 10s, and the pool covers that up, fixing that bug and removing the pool could lead to better results. If it turns out there is only 3% extra churn but that extra churn causes a 10x perf reduction in GC, then we better understand those limits and potentially work with the openjdk team in that area. > > This conversation is a perfect example of misinformation that causes us performance and scalability problems within our code bases. It?s just a surprising result. The pool saves a few allocations, but it also has the cost of concurrency usage which can trigger blocking, additional barriers, and busy looping on CAS. You also still have object churn in the underlying pool data structures that occurs per invocation since every invocation is a check-out and a check-in (requires a new node object instance), and if the semaphore blocks you have additional allocation for the entry in the wait queue. You factor in the remaining allocation savings relative to other allocations that are required for the invocation, and it should be a very small percentage. For that very small percentage to lead to several times a difference in performance to me hints at other factors being involved. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From rodakr at gmx.ch Wed Aug 6 13:15:09 2014 From: rodakr at gmx.ch (Radoslaw Rodak) Date: Wed, 6 Aug 2014 19:15:09 +0200 Subject: [wildfly-dev] Fwd: Pooling EJB Session Beans per default References: <2182EED1-F15D-4322-AA10-94F996F83432@gmx.ch> Message-ID: <1845653B-5B0F-4994-9340-705334038B5F@gmx.ch> Anfang der weitergeleiteten Nachricht: > Von: Radoslaw Rodak > Betreff: Aw: [wildfly-dev] Pooling EJB Session Beans per default > Datum: 6. August 2014 19:06:01 MESZ > An: Andrig Miller > > > Am 06.08.2014 um 16:50 schrieb Andrig Miller : > >> >> >> ----- Original Message ----- >>> From: "Radoslaw Rodak" >>> To: wildfly-dev at lists.jboss.org >>> Sent: Tuesday, August 5, 2014 6:51:03 PM >>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>> >>> >>> Am 06.08.2014 um 00:36 schrieb Bill Burke : >>> >>>> >>>> >>>> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>>>> Its a horrible theory. :) How many EJB instances of a give type >>>>>> are >>>>>> created per request? Generally only 1. 1 instance of one object >>>>>> of >>>>>> one >>>>>> type! My $5 bet is that if you went into EJB code and started >>>>>> counting >>>>>> how many object allocations were made per request, you'd lose >>>>>> count >>>>>> very >>>>>> quickly. Better yet, run a single remote EJB request through a >>>>>> perf >>>>>> tool and let it count the number of allocations for you. It will >>>>>> be >>>>>> greater than 1. :) >>>>>> >>>>>> Maybe the StrictMaxPool has an effect on performance because it >>>>>> creates >>>>>> a global synchronization bottleneck. Throughput is less and you >>>>>> end >>>>>> up >>>>>> having less concurrent per-request objects being allocated and >>>>>> GC'd. >>>>>> >>>>> >>>>> The number per request, while relevant is only part of the story. >>>>> The number of concurrent requests happening in the server >>>>> dictates the object allocation rate. Given enough concurrency, >>>>> even a very small number of object allocations per request can >>>>> create an object allocation rate that can no longer be sustained. >>>>> >>>> >>>> I'm saying that the number of concurrent requests might not dictate >>>> object allocation rate. There are probably a number of allocations >>>> that >>>> happen after the EJB instance is obtained. i.e. interception >>>> chains, >>>> contexts, etc. If StrictMaxPool blocks until a new instance is >>>> available, then there would be less allocations per request as >>>> blocking >>>> threads would be serialized. >>>> >>> >>> Scenarion 1 ) >>> ------------------ >>> Let say we have a pool of 100 Stateless EJBs and a constant Load of >>> 50 Requests per second proceeded by 50 EJBs from the pool in one >>> second. >>> After 1000 seconds how many new EJB Instances will be created having >>> a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course >>> object allocation is much higher as of course 1 EJB call leads to >>> many Object from one EJB but?let see situation without pool. >>> >>> 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on >>> Java heap where 1 EJB might have many objects? as long as Garbage >>> Collection was not triggered? which sounds to me like faster filling >>> JVM heap and having ofter GC probable depending on GC Strategy. >>> >>> Scenarion 2) >>> ------------------ >>> Same as before, Load is still 50 Requests per second BUT EJB Method >>> call takes 10s. >>> after 10s we have 500 EJB Instances without pool, after 11s 550 - 10 >>> = 540EJB Instances , after 12s 580 EJBs ? after some time very bad >>> perf?full GC ?and mabe OutOfMemory.. >>> >>> So? performance advantage could also turn in to disadvantage :-) >>> >>> >>>> Whoever is investigating StrictMaxPool, or EJB pooling in general >>>> should >>>> stop. Its pointless. >>> >>> Agree, pools are outdated?. but something like WorkManager for min, >>> max Threads or even better always not less the X idle Threads would >>> be useful :-) >>> >>> Radek >>> >> >> The scenarios above are what is outddated. Fifty requests per second isn't any load at all! We have 100's of thousands of clients that we have to scale to, and lots more than 50 requests per second. >> >> Andy > > It?s not about size of load unit, it?s about behavior with and without pool with load over period of time with side effects :-) > Just Number of Clients doesn?t matter so much? but number concurrent requests from the clients per time unit... > > >> >>> >>> >>> >>> _______________________________________________ >>> 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/20140806/faffcc97/attachment.html From rodakr at gmx.ch Wed Aug 6 13:15:25 2014 From: rodakr at gmx.ch (Radoslaw Rodak) Date: Wed, 6 Aug 2014 19:15:25 +0200 Subject: [wildfly-dev] Fwd: Pooling EJB Session Beans per default References: <2354A9D2-D484-4761-869B-0AAC841D1230@gmx.ch> Message-ID: <0E8E4443-95B1-42F9-9BE6-200ECCC81BA5@gmx.ch> Anfang der weitergeleiteten Nachricht: > Von: Radoslaw Rodak > Betreff: Aw: [wildfly-dev] Pooling EJB Session Beans per default > Datum: 6. August 2014 19:14:18 MESZ > An: Jason Greene > > > Am 06.08.2014 um 17:13 schrieb Jason Greene : > >> >> On Aug 5, 2014, at 7:51 PM, Radoslaw Rodak wrote: >> >>> >>> Am 06.08.2014 um 00:36 schrieb Bill Burke : >>> >>>> >>>> >>>> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>>>> Its a horrible theory. :) How many EJB instances of a give type are >>>>>> created per request? Generally only 1. 1 instance of one object of >>>>>> one >>>>>> type! My $5 bet is that if you went into EJB code and started >>>>>> counting >>>>>> how many object allocations were made per request, you'd lose count >>>>>> very >>>>>> quickly. Better yet, run a single remote EJB request through a perf >>>>>> tool and let it count the number of allocations for you. It will be >>>>>> greater than 1. :) >>>>>> >>>>>> Maybe the StrictMaxPool has an effect on performance because it >>>>>> creates >>>>>> a global synchronization bottleneck. Throughput is less and you end >>>>>> up >>>>>> having less concurrent per-request objects being allocated and GC'd. >>>>>> >>>>> >>>>> The number per request, while relevant is only part of the story. The number of concurrent requests happening in the server dictates the object allocation rate. Given enough concurrency, even a very small number of object allocations per request can create an object allocation rate that can no longer be sustained. >>>>> >>>> >>>> I'm saying that the number of concurrent requests might not dictate >>>> object allocation rate. There are probably a number of allocations that >>>> happen after the EJB instance is obtained. i.e. interception chains, >>>> contexts, etc. If StrictMaxPool blocks until a new instance is >>>> available, then there would be less allocations per request as blocking >>>> threads would be serialized. >>>> >>> >>> Scenarion 1 ) >>> ------------------ >>> Let say we have a pool of 100 Stateless EJBs and a constant Load of 50 Requests per second proceeded by 50 EJBs from the pool in one second. >>> After 1000 seconds how many new EJB Instances will be created having a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course object allocation is much higher as of course 1 EJB call leads to many Object from one EJB but?let see situation without pool. >>> >>> 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on Java heap where 1 EJB might have many objects? as long as Garbage Collection was not triggered? which sounds to me like faster filling JVM heap and having ofter GC probable depending on GC Strategy. >> >> If you think about a single Java EE request invocation that processes data with one EJB in the call, there is typically hundreds of temporary objects created (perhaps even thousands when you are pulling back many rows of data from JPA). Aside from the container API requirements (the container has to create a string for every http header name and value, which can easily be 20+ objects), just writing plain java code that does things like substring creates temporary objects. Now, I don?t have an exact object instance count for an SLSB creation, but glancing at the code it looks ~ 6 objects. So we are talking about a very small percentage of object space, probably around 1-2%. >> >> On the other hand the percentage could be high if you have an ejb method that doesn?t do much (e.g. just returns a constant) and you call it in a big loop as part of a request. Then you could get 6 * N object churn, which could very well end up to be a high percentage (for a large enough value of N). >> > > This is exactly what I was trying to point! > > > >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140806/02be1ae6/attachment.html From rodakr at gmx.ch Wed Aug 6 13:21:37 2014 From: rodakr at gmx.ch (Radoslaw Rodak) Date: Wed, 6 Aug 2014 19:21:37 +0200 Subject: [wildfly-dev] Fwd: Pooling EJB Session Beans per default References: <00DC5324-454E-4222-BCFF-C3BA605A8E21@gmx.ch> Message-ID: <969A1E76-C62B-4FB9-979E-5FAF70FFA355@gmx.ch> Anfang der weitergeleiteten Nachricht: > Von: Radoslaw Rodak > Betreff: Aw: [wildfly-dev] Pooling EJB Session Beans per default > Datum: 6. August 2014 19:20:07 MESZ > An: Bill Burke > > > Am 06.08.2014 um 17:30 schrieb Bill Burke : > >> >> >> On 8/6/2014 10:50 AM, Andrig Miller wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Radoslaw Rodak" >>>> To: wildfly-dev at lists.jboss.org >>>> Sent: Tuesday, August 5, 2014 6:51:03 PM >>>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>>> >>>> >>>> Am 06.08.2014 um 00:36 schrieb Bill Burke : >>>> >>>>> >>>>> >>>>> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>>>>> Its a horrible theory. :) How many EJB instances of a give type >>>>>>> are >>>>>>> created per request? Generally only 1. 1 instance of one object >>>>>>> of >>>>>>> one >>>>>>> type! My $5 bet is that if you went into EJB code and started >>>>>>> counting >>>>>>> how many object allocations were made per request, you'd lose >>>>>>> count >>>>>>> very >>>>>>> quickly. Better yet, run a single remote EJB request through a >>>>>>> perf >>>>>>> tool and let it count the number of allocations for you. It will >>>>>>> be >>>>>>> greater than 1. :) >>>>>>> >>>>>>> Maybe the StrictMaxPool has an effect on performance because it >>>>>>> creates >>>>>>> a global synchronization bottleneck. Throughput is less and you >>>>>>> end >>>>>>> up >>>>>>> having less concurrent per-request objects being allocated and >>>>>>> GC'd. >>>>>>> >>>>>> >>>>>> The number per request, while relevant is only part of the story. >>>>>> The number of concurrent requests happening in the server >>>>>> dictates the object allocation rate. Given enough concurrency, >>>>>> even a very small number of object allocations per request can >>>>>> create an object allocation rate that can no longer be sustained. >>>>>> >>>>> >>>>> I'm saying that the number of concurrent requests might not dictate >>>>> object allocation rate. There are probably a number of allocations >>>>> that >>>>> happen after the EJB instance is obtained. i.e. interception >>>>> chains, >>>>> contexts, etc. If StrictMaxPool blocks until a new instance is >>>>> available, then there would be less allocations per request as >>>>> blocking >>>>> threads would be serialized. >>>>> >>>> >>>> Scenarion 1 ) >>>> ------------------ >>>> Let say we have a pool of 100 Stateless EJBs and a constant Load of >>>> 50 Requests per second proceeded by 50 EJBs from the pool in one >>>> second. >>>> After 1000 seconds how many new EJB Instances will be created having >>>> a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of course >>>> object allocation is much higher as of course 1 EJB call leads to >>>> many Object from one EJB but?let see situation without pool. >>>> >>>> 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances on >>>> Java heap where 1 EJB might have many objects? as long as Garbage >>>> Collection was not triggered? which sounds to me like faster filling >>>> JVM heap and having ofter GC probable depending on GC Strategy. >>>> >>>> Scenarion 2) >>>> ------------------ >>>> Same as before, Load is still 50 Requests per second BUT EJB Method >>>> call takes 10s. >>>> after 10s we have 500 EJB Instances without pool, after 11s 550 - 10 >>>> = 540EJB Instances , after 12s 580 EJBs ? after some time very bad >>>> perf?full GC ?and mabe OutOfMemory.. >>>> >>>> So? performance advantage could also turn in to disadvantage :-) >>>> >>>> >>>>> Whoever is investigating StrictMaxPool, or EJB pooling in general >>>>> should >>>>> stop. Its pointless. >>>> >>>> Agree, pools are outdated?. but something like WorkManager for min, >>>> max Threads or even better always not less the X idle Threads would >>>> be useful :-) >>>> >>>> Radek >>>> >>> >>> The scenarios above are what is outddated. Fifty requests per second isn't any load at all! We have 100's of thousands of clients that we have to scale to, and lots more than 50 requests per second. >>> >> What you mean to say is that you need to scale to 100's of thousands of >> clients on meaningless no-op benchmarks. :) I do know that that old >> SpecJ Java EE benchmarks artifically made EJB pooling important as >> process intensive calculation results were cached in these instances. >> But real-world apps don't use this feature/anti-pattern. >> >> Also however crappy it was, I did implement an EJB container at one time >> in my career. :) I know for a fact that there are a number of >> per-request internal support objects that need to be allocated. Let's >> count: >> >> * The argument array (for reflection) >> * Each argument of the method call >> * The response object >> * Interceptor context object >> * The interceptor context attribute map >> * EJBContext >> * Subject, Principal, role mappings >> * Transaction context >> * The message object(s) specific to the remote EJB protocol >> >> Starts to add up huh? I'm probably missing a bunch more. Throw in >> interaction with JPA and you end up with even more per-request objects >> being allocated. You still believe pooling one EJB instance matters? >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > Totally agree! > The point is, pool has not only pool but also throttling function. > If you remove pool you still need throttling and you might have better performance over time with throttling as without and run out of resources... > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140806/be6d8e79/attachment-0001.html From anmiller at redhat.com Wed Aug 6 13:21:48 2014 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 6 Aug 2014 13:21:48 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <08F39457-CF7D-4F6F-9343-2251F0EB2562@redhat.com> References: <53CD3CCE.2030902@imixs.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> <24380467.708.1407340144909.JavaMail.andrig@worklaptop.miller.org> <08F39457-CF7D-4F6F-9343-2251F0EB2562@redhat.com> Message-ID: <32516037.1227.1407345705751.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Jason Greene" > To: "Andrig Miller" > Cc: "Bill Burke" , wildfly-dev at lists.jboss.org > Sent: Wednesday, August 6, 2014 11:08:02 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > On Aug 6, 2014, at 10:49 AM, Andrig Miller > wrote: > > > > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: wildfly-dev at lists.jboss.org > >> Sent: Wednesday, August 6, 2014 9:30:06 AM > >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > >> > >> > >> > >> On 8/6/2014 10:50 AM, Andrig Miller wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Radoslaw Rodak" > >>>> To: wildfly-dev at lists.jboss.org > >>>> Sent: Tuesday, August 5, 2014 6:51:03 PM > >>>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > >>>> > >>>> > >>>> Am 06.08.2014 um 00:36 schrieb Bill Burke : > >>>> > >>>>> > >>>>> > >>>>> On 8/5/2014 3:54 PM, Andrig Miller wrote: > >>>>>>> Its a horrible theory. :) How many EJB instances of a give > >>>>>>> type > >>>>>>> are > >>>>>>> created per request? Generally only 1. 1 instance of one > >>>>>>> object > >>>>>>> of > >>>>>>> one > >>>>>>> type! My $5 bet is that if you went into EJB code and > >>>>>>> started > >>>>>>> counting > >>>>>>> how many object allocations were made per request, you'd lose > >>>>>>> count > >>>>>>> very > >>>>>>> quickly. Better yet, run a single remote EJB request > >>>>>>> through > >>>>>>> a > >>>>>>> perf > >>>>>>> tool and let it count the number of allocations for you. It > >>>>>>> will > >>>>>>> be > >>>>>>> greater than 1. :) > >>>>>>> > >>>>>>> Maybe the StrictMaxPool has an effect on performance because > >>>>>>> it > >>>>>>> creates > >>>>>>> a global synchronization bottleneck. Throughput is less and > >>>>>>> you > >>>>>>> end > >>>>>>> up > >>>>>>> having less concurrent per-request objects being allocated > >>>>>>> and > >>>>>>> GC'd. > >>>>>>> > >>>>>> > >>>>>> The number per request, while relevant is only part of the > >>>>>> story. > >>>>>> The number of concurrent requests happening in the server > >>>>>> dictates the object allocation rate. Given enough > >>>>>> concurrency, > >>>>>> even a very small number of object allocations per request can > >>>>>> create an object allocation rate that can no longer be > >>>>>> sustained. > >>>>>> > >>>>> > >>>>> I'm saying that the number of concurrent requests might not > >>>>> dictate > >>>>> object allocation rate. There are probably a number of > >>>>> allocations > >>>>> that > >>>>> happen after the EJB instance is obtained. i.e. interception > >>>>> chains, > >>>>> contexts, etc. If StrictMaxPool blocks until a new instance > >>>>> is > >>>>> available, then there would be less allocations per request as > >>>>> blocking > >>>>> threads would be serialized. > >>>>> > >>>> > >>>> Scenarion 1 ) > >>>> ------------------ > >>>> Let say we have a pool of 100 Stateless EJBs and a constant Load > >>>> of > >>>> 50 Requests per second proceeded by 50 EJBs from the pool in > >>>> one > >>>> second. > >>>> After 1000 seconds how many new EJB Instances will be created > >>>> having > >>>> a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of > >>>> course > >>>> object allocation is much higher as of course 1 EJB call leads > >>>> to > >>>> many Object from one EJB but?let see situation without pool. > >>>> > >>>> 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances > >>>> on > >>>> Java heap where 1 EJB might have many objects? as long as > >>>> Garbage > >>>> Collection was not triggered? which sounds to me like faster > >>>> filling > >>>> JVM heap and having ofter GC probable depending on GC Strategy. > >>>> > >>>> Scenarion 2) > >>>> ------------------ > >>>> Same as before, Load is still 50 Requests per second BUT EJB > >>>> Method > >>>> call takes 10s. > >>>> after 10s we have 500 EJB Instances without pool, after 11s 550 > >>>> - > >>>> 10 > >>>> = 540EJB Instances , after 12s 580 EJBs ? after some time very > >>>> bad > >>>> perf?full GC ?and mabe OutOfMemory.. > >>>> > >>>> So? performance advantage could also turn in to disadvantage :-) > >>>> > >>>> > >>>>> Whoever is investigating StrictMaxPool, or EJB pooling in > >>>>> general > >>>>> should > >>>>> stop. Its pointless. > >>>> > >>>> Agree, pools are outdated?. but something like WorkManager for > >>>> min, > >>>> max Threads or even better always not less the X idle Threads > >>>> would > >>>> be useful :-) > >>>> > >>>> Radek > >>>> > >>> > >>> The scenarios above are what is outddated. Fifty requests per > >>> second isn't any load at all! We have 100's of thousands of > >>> clients that we have to scale to, and lots more than 50 requests > >>> per second. > >>> > >> What you mean to say is that you need to scale to 100's of > >> thousands > >> of > >> clients on meaningless no-op benchmarks. :) I do know that that > >> old > >> SpecJ Java EE benchmarks artifically made EJB pooling important as > >> process intensive calculation results were cached in these > >> instances. > >> But real-world apps don't use this feature/anti-pattern. > >> > > > > I am not talking about a meaningless no-op benchmark, but a > > benchmark that does lots of work. We don't use meaningless no-op > > benchmarks on the performance team, with some exception for > > microbenchmarks that we have carefully crafted that model the > > interactions for a specific component within the context of how it > > is actually used for a real application. > > > >> Also however crappy it was, I did implement an EJB container at > >> one > >> time > >> in my career. :) I know for a fact that there are a number of > >> per-request internal support objects that need to be allocated. > >> Let's > >> count: > >> > >> * The argument array (for reflection) > >> * Each argument of the method call > >> * The response object > >> * Interceptor context object > >> * The interceptor context attribute map > >> * EJBContext > >> * Subject, Principal, role mappings > >> * Transaction context > >> * The message object(s) specific to the remote EJB protocol > >> > >> Starts to add up huh? I'm probably missing a bunch more. Throw > >> in > >> interaction with JPA and you end up with even more per-request > >> objects > >> being allocated. You still believe pooling one EJB instance > >> matters? > >> > > > > See John O'Hara's post which shows our non-meaningless benchmark > > and the difference that pooling makes vs. non-pooling. It is a > > dramatic difference to say the least. > > There is certainly a correlation identified between the results of > this benchmark and the use of pooling. However the underlying cause > of the resulting difference is still unknown. If we knew > definitively how and why this happens it would help in optimizing > this further. As an example, if it turned out to be some secondary > factor, like the throttling aspect of the pool, then eliminating > these allocations (and others) with a zero-tuning approach, like > thread local pooling would offer little to no improvement. If > discovered it is indeed extreme object allocation, and that it came > from thousands of nested calls in a request, then having a temporary > per-request thread local cache would dramatically improve the > results, and be cheap/quick to implement vs a full thread local > solution. If there is a bug in our code somewhere where under > certain situations we create hundreds of objects, when we should be > creating 10s, and the pool covers that up, fixing that bug and > removing the pool could lead to better results. If it turns out > there is only 3% extra churn but that extra churn causes a 10x perf > reduction in GC, then we better understand those limits and > potentially work with the openjdk team in that area. > > > > > > This conversation is a perfect example of misinformation that > > causes us performance and scalability problems within our code > > bases. > > It?s just a surprising result. The pool saves a few allocations, but > it also has the cost of concurrency usage which can trigger > blocking, additional barriers, and busy looping on CAS. You also > still have object churn in the underlying pool data structures that > occurs per invocation since every invocation is a check-out and a > check-in (requires a new node object instance), and if the semaphore > blocks you have additional allocation for the entry in the wait > queue. You factor in the remaining allocation savings relative to > other allocations that are required for the invocation, and it > should be a very small percentage. For that very small percentage to > lead to several times a difference in performance to me hints at > other factors being involved. > All logically thought through. At a 15% lower transaction rate than we are doing now, we saw 4 Gigabytes per second of object allocation. We, with Sanne doing most of the work, managed to get that down to 3 Gigabytes per second (I would have loved to get it to 2). Much of that was Hibernate allocations, and of course that was with pooling on. We have not spent the time to pinpoint the exact differences, memory and other, between having pooling on vs. off. Our priority has been continue to scale the workload and fix any problems we see as a result. We have managed to increase the transaction rate another 15% in the last couple of months, but still have another 17+% to go on a single JVM before we start looking at two JVM's for the testing. Once we get to our goal, I would love to put this on our list of tasks, so we can get the specific facts, and instead of talking theory, we will no exactly what can and cannot be done, and whether no pooling could ever match pooled. Andy > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > From rodakr at gmx.ch Wed Aug 6 13:32:55 2014 From: rodakr at gmx.ch (Radoslaw Rodak) Date: Wed, 6 Aug 2014 19:32:55 +0200 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E2473F.6070108@redhat.com> References: <53CD3CCE.2030902@imixs.com> <27798766.3810.1407246182746.JavaMail.andrig@worklaptop.miller.org> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <25320436.672.1407336470565.JavaMail.andrig@worklaptop.miller.org> <53E2473F.6070108@redhat.com> Message-ID: <7FEC363A-286F-4B60-B693-A847B945DE05@gmx.ch> Am 06.08.2014 um 17:18 schrieb John O'Hara : > On 08/06/2014 03:47 PM, Andrig Miller wrote: >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: "Andrig Miller" >>> Cc: wildfly-dev at lists.jboss.org, "Jason Greene" >>> Sent: Tuesday, August 5, 2014 4:36:11 PM >>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>> >>> >>> >>> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>>> Its a horrible theory. :) How many EJB instances of a give type >>>>> are >>>>> created per request? Generally only 1. 1 instance of one object >>>>> of >>>>> one >>>>> type! My $5 bet is that if you went into EJB code and started >>>>> counting >>>>> how many object allocations were made per request, you'd lose >>>>> count >>>>> very >>>>> quickly. Better yet, run a single remote EJB request through a >>>>> perf >>>>> tool and let it count the number of allocations for you. It will >>>>> be >>>>> greater than 1. :) >>>>> >>>>> Maybe the StrictMaxPool has an effect on performance because it >>>>> creates >>>>> a global synchronization bottleneck. Throughput is less and you >>>>> end >>>>> up >>>>> having less concurrent per-request objects being allocated and >>>>> GC'd. >>>>> >>>> The number per request, while relevant is only part of the story. >>>> The number of concurrent requests happening in the server >>>> dictates the object allocation rate. Given enough concurrency, >>>> even a very small number of object allocations per request can >>>> create an object allocation rate that can no longer be sustained. >>>> >>> I'm saying that the number of concurrent requests might not dictate >>> object allocation rate. There are probably a number of allocations >>> that >>> happen after the EJB instance is obtained. i.e. interception chains, >>> contexts, etc. If StrictMaxPool blocks until a new instance is >>> available, then there would be less allocations per request as >>> blocking >>> threads would be serialized. >>> >>> Whoever is investigating StrictMaxPool, or EJB pooling in general >>> should >>> stop. Its pointless. >>> >> Ah, no its not pointless. We have a new non-blocking implementation of StrictMaxPool, and its upstream in Wildfly 9, and will be in EAP 6.4. It has helped us increase our throughput, and reduce response times alot! >> >> Andy > Some contextual numbers around what Andy is describing. These are results from one of our benchmarks; > > Average response times (28600 concurrent users) > Pooled > Non-pooled > Remote EJB invocations > 0.114s 2.094s > WS invocations > 0.105s 0.332s > HTTP web app invocations > > > HttpCallTypeA > 0.090s 5.589s > HttpCallTypeB 0.042s 2.510s > HttpCallTypeC 0.116s 7.267S > The only difference between these two sets of numbers is EJB pooling. I guess this are just average numbers?. do you have graphics with response in function of time during the loadtest? And how much time JVM spent doing GC? with both tests? Dynatrace has nice integration with jenkins to generate such reports. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140806/50606d45/attachment.html From jason.greene at redhat.com Wed Aug 6 13:37:07 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 6 Aug 2014 12:37:07 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53E249FE.2010704@redhat.com> References: <53CD3CCE.2030902@imixs.com> <70D8F222-A537-4B3B-AD5A-37DE5EA579B1@redhat.com> <53E0EAEF.1010703@redhat.com> <4B10E6FA-945D-467D-A5DF-CBEE7E1033DA@redhat.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> Message-ID: <1F7596F8-5214-43BC-8478-772D96D678E0@redhat.com> On Aug 6, 2014, at 10:30 AM, Bill Burke wrote: > What you mean to say is that you need to scale to 100's of thousands of > clients on meaningless no-op benchmarks. :) I do know that that old > SpecJ Java EE benchmarks artifically made EJB pooling important as > process intensive calculation results were cached in these instances. > But real-world apps don't use this feature/anti-pattern. If the benchmark in question is doing that, that would most definitely explain this. I mean we know the following can perform poorly without pooling: 1. Expensive initialization in @PostConstruct 2. Lazy expensive initialization in a invocation (what you allude to above) 3. Expensive initialization in a constructor Large allocations of objects count as expensive initialization. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Wed Aug 6 13:48:53 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 6 Aug 2014 12:48:53 -0500 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <32516037.1227.1407345705751.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> <24380467.708.1407340144909.JavaMail.andrig@worklaptop.miller.org> <08F39457-CF7D-4F6F-9343-2251F0EB2562@redhat.com> <32516037.1227.1407345705751.JavaMail.andrig@worklaptop.miller.org> Message-ID: On Aug 6, 2014, at 12:21 PM, Andrig Miller wrote: > > > ----- Original Message ----- >> From: "Jason Greene" >> To: "Andrig Miller" >> Cc: "Bill Burke" , wildfly-dev at lists.jboss.org >> Sent: Wednesday, August 6, 2014 11:08:02 AM >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >> >> >> On Aug 6, 2014, at 10:49 AM, Andrig Miller >> wrote: >> >>> >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: wildfly-dev at lists.jboss.org >>>> Sent: Wednesday, August 6, 2014 9:30:06 AM >>>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>>> >>> >>> This conversation is a perfect example of misinformation that >>> causes us performance and scalability problems within our code >>> bases. >> >> It?s just a surprising result. The pool saves a few allocations, but >> it also has the cost of concurrency usage which can trigger >> blocking, additional barriers, and busy looping on CAS. You also >> still have object churn in the underlying pool data structures that >> occurs per invocation since every invocation is a check-out and a >> check-in (requires a new node object instance), and if the semaphore >> blocks you have additional allocation for the entry in the wait >> queue. You factor in the remaining allocation savings relative to >> other allocations that are required for the invocation, and it >> should be a very small percentage. For that very small percentage to >> lead to several times a difference in performance to me hints at >> other factors being involved. >> > > All logically thought through. At a 15% lower transaction rate than we are doing now, we saw 4 Gigabytes per second of object allocation. We, with Sanne doing most of the work, managed to get that down to 3 Gigabytes per second (I would have loved to get it to 2). Much of that was Hibernate allocations, and of course that was with pooling on. We have not spent the time to pinpoint the exact differences, memory and other, between having pooling on vs. off. Our priority has been continue to scale the workload and fix any problems we see as a result. We have managed to increase the transaction rate another 15% in the last couple of months, but still have another 17+% to go on a single JVM before we start looking at two JVM's for the testing. > > Once we get to our goal, I would love to put this on our list of tasks, so we can get the specific facts, and instead of talking theory, we will no exactly what can and cannot be done, and whether no pooling could ever match pooled. Fair enough, and I certainly didn?t mean to imply that such work should be your team, I was just speaking generally. In any case, what I really really would like for us to achieve is a default implementation that performs generally well on all usage patterns, with no tuning required. Since we know that initialization can be costly for some applications usage of SLSB, such an implementation will definitely require a form of pooling. I suspect that a thread local based design with the pooling tied to worker threads will give us this. Alternatively a shared pool which is auto-tuned to match might be worth looking into. If there is anyone lurking who wishes to contribute in this area speak up, and I?ll worth with you on it. As doge would say ?Such Fun. Much Glory? :) -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From rodakr at gmx.ch Wed Aug 6 14:08:21 2014 From: rodakr at gmx.ch (Radoslaw Rodak) Date: Wed, 6 Aug 2014 20:08:21 +0200 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: References: <53CD3CCE.2030902@imixs.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> <24380467.708.1407340144909.JavaMail.andrig@worklaptop.miller.org> <08F39457-CF7D-4F6F-9343-2251F0EB2562@redhat.com> <32516037.1227.1407345705751.JavaMail.andrig@worklaptop.miller.org> Message-ID: Am 06.08.2014 um 19:48 schrieb Jason Greene : > > On Aug 6, 2014, at 12:21 PM, Andrig Miller wrote: > >> >> >> ----- Original Message ----- >>> From: "Jason Greene" >>> To: "Andrig Miller" >>> Cc: "Bill Burke" , wildfly-dev at lists.jboss.org >>> Sent: Wednesday, August 6, 2014 11:08:02 AM >>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>> >>> >>> On Aug 6, 2014, at 10:49 AM, Andrig Miller >>> wrote: >>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Burke" >>>>> To: wildfly-dev at lists.jboss.org >>>>> Sent: Wednesday, August 6, 2014 9:30:06 AM >>>>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>>>> >>>> > > >>>> This conversation is a perfect example of misinformation that >>>> causes us performance and scalability problems within our code >>>> bases. >>> >>> It?s just a surprising result. The pool saves a few allocations, but >>> it also has the cost of concurrency usage which can trigger >>> blocking, additional barriers, and busy looping on CAS. You also >>> still have object churn in the underlying pool data structures that >>> occurs per invocation since every invocation is a check-out and a >>> check-in (requires a new node object instance), and if the semaphore >>> blocks you have additional allocation for the entry in the wait >>> queue. You factor in the remaining allocation savings relative to >>> other allocations that are required for the invocation, and it >>> should be a very small percentage. For that very small percentage to >>> lead to several times a difference in performance to me hints at >>> other factors being involved. >>> >> >> All logically thought through. At a 15% lower transaction rate than we are doing now, we saw 4 Gigabytes per second of object allocation. We, with Sanne doing most of the work, managed to get that down to 3 Gigabytes per second (I would have loved to get it to 2). Much of that was Hibernate allocations, and of course that was with pooling on. We have not spent the time to pinpoint the exact differences, memory and other, between having pooling on vs. off. Our priority has been continue to scale the workload and fix any problems we see as a result. We have managed to increase the transaction rate another 15% in the last couple of months, but still have another 17+% to go on a single JVM before we start looking at two JVM's for the testing. >> >> Once we get to our goal, I would love to put this on our list of tasks, so we can get the specific facts, and instead of talking theory, we will no exactly what can and cannot be done, and whether no pooling could ever match pooled. > > Fair enough, and I certainly didn?t mean to imply that such work should be your team, I was just speaking generally. In any case, what I really really would like for us to achieve is a default implementation that performs generally well on all usage patterns, with no tuning required. Since we know that initialization can be costly for some applications usage of SLSB, such an implementation will definitely require a form of pooling. > > I suspect that a thread local based design with the pooling tied to worker threads will give us this. Alternatively a shared pool which is auto-tuned to match might be worth looking into. > > If there is anyone lurking who wishes to contribute in this area speak up, and I?ll worth with you on it. As doge would say ?Such Fun. Much Glory? :) I would expect something better then this :-))) http://de.slideshare.net/jambay/weblogic-server-work-managers-and-overload-protection > > -- > 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/20140806/d0b9a064/attachment.html From rodakr at gmx.ch Wed Aug 6 14:29:59 2014 From: rodakr at gmx.ch (Radoslaw Rodak) Date: Wed, 6 Aug 2014 20:29:59 +0200 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <32516037.1227.1407345705751.JavaMail.andrig@worklaptop.miller.org> References: <53CD3CCE.2030902@imixs.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> <24380467.708.1407340144909.JavaMail.andrig@worklaptop.miller.org> <08F39457-CF7D-4F6F-9343-2251F0EB2562@redhat.com> <32516037.1227.1407345705751.JavaMail.andrig@worklaptop.miller.org> Message-ID: <7E0A89B1-330E-43F4-B244-3E06A2C38AAC@gmx.ch> Am 06.08.2014 um 19:21 schrieb Andrig Miller : > > > ----- Original Message ----- >> From: "Jason Greene" >> To: "Andrig Miller" >> Cc: "Bill Burke" , wildfly-dev at lists.jboss.org >> Sent: Wednesday, August 6, 2014 11:08:02 AM >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >> >> >> On Aug 6, 2014, at 10:49 AM, Andrig Miller >> wrote: >> >>> >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: wildfly-dev at lists.jboss.org >>>> Sent: Wednesday, August 6, 2014 9:30:06 AM >>>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>>> >>>> >>>> >>>> On 8/6/2014 10:50 AM, Andrig Miller wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Radoslaw Rodak" >>>>>> To: wildfly-dev at lists.jboss.org >>>>>> Sent: Tuesday, August 5, 2014 6:51:03 PM >>>>>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>>>>> >>>>>> >>>>>> Am 06.08.2014 um 00:36 schrieb Bill Burke : >>>>>> >>>>>>> >>>>>>> >>>>>>> On 8/5/2014 3:54 PM, Andrig Miller wrote: >>>>>>>>> Its a horrible theory. :) How many EJB instances of a give >>>>>>>>> type >>>>>>>>> are >>>>>>>>> created per request? Generally only 1. 1 instance of one >>>>>>>>> object >>>>>>>>> of >>>>>>>>> one >>>>>>>>> type! My $5 bet is that if you went into EJB code and >>>>>>>>> started >>>>>>>>> counting >>>>>>>>> how many object allocations were made per request, you'd lose >>>>>>>>> count >>>>>>>>> very >>>>>>>>> quickly. Better yet, run a single remote EJB request >>>>>>>>> through >>>>>>>>> a >>>>>>>>> perf >>>>>>>>> tool and let it count the number of allocations for you. It >>>>>>>>> will >>>>>>>>> be >>>>>>>>> greater than 1. :) >>>>>>>>> >>>>>>>>> Maybe the StrictMaxPool has an effect on performance because >>>>>>>>> it >>>>>>>>> creates >>>>>>>>> a global synchronization bottleneck. Throughput is less and >>>>>>>>> you >>>>>>>>> end >>>>>>>>> up >>>>>>>>> having less concurrent per-request objects being allocated >>>>>>>>> and >>>>>>>>> GC'd. >>>>>>>>> >>>>>>>> >>>>>>>> The number per request, while relevant is only part of the >>>>>>>> story. >>>>>>>> The number of concurrent requests happening in the server >>>>>>>> dictates the object allocation rate. Given enough >>>>>>>> concurrency, >>>>>>>> even a very small number of object allocations per request can >>>>>>>> create an object allocation rate that can no longer be >>>>>>>> sustained. >>>>>>>> >>>>>>> >>>>>>> I'm saying that the number of concurrent requests might not >>>>>>> dictate >>>>>>> object allocation rate. There are probably a number of >>>>>>> allocations >>>>>>> that >>>>>>> happen after the EJB instance is obtained. i.e. interception >>>>>>> chains, >>>>>>> contexts, etc. If StrictMaxPool blocks until a new instance >>>>>>> is >>>>>>> available, then there would be less allocations per request as >>>>>>> blocking >>>>>>> threads would be serialized. >>>>>>> >>>>>> >>>>>> Scenarion 1 ) >>>>>> ------------------ >>>>>> Let say we have a pool of 100 Stateless EJBs and a constant Load >>>>>> of >>>>>> 50 Requests per second proceeded by 50 EJBs from the pool in >>>>>> one >>>>>> second. >>>>>> After 1000 seconds how many new EJB Instances will be created >>>>>> having >>>>>> a pool? answer 0 new EJBs worst case 100 EJB?s in pool? of >>>>>> course >>>>>> object allocation is much higher as of course 1 EJB call leads >>>>>> to >>>>>> many Object from one EJB but?let see situation without pool. >>>>>> >>>>>> 50 Request/s * 1000 seconds = worst case 50? 000 EJB Instances >>>>>> on >>>>>> Java heap where 1 EJB might have many objects? as long as >>>>>> Garbage >>>>>> Collection was not triggered? which sounds to me like faster >>>>>> filling >>>>>> JVM heap and having ofter GC probable depending on GC Strategy. >>>>>> >>>>>> Scenarion 2) >>>>>> ------------------ >>>>>> Same as before, Load is still 50 Requests per second BUT EJB >>>>>> Method >>>>>> call takes 10s. >>>>>> after 10s we have 500 EJB Instances without pool, after 11s 550 >>>>>> - >>>>>> 10 >>>>>> = 540EJB Instances , after 12s 580 EJBs ? after some time very >>>>>> bad >>>>>> perf?full GC ?and mabe OutOfMemory.. >>>>>> >>>>>> So? performance advantage could also turn in to disadvantage :-) >>>>>> >>>>>> >>>>>>> Whoever is investigating StrictMaxPool, or EJB pooling in >>>>>>> general >>>>>>> should >>>>>>> stop. Its pointless. >>>>>> >>>>>> Agree, pools are outdated?. but something like WorkManager for >>>>>> min, >>>>>> max Threads or even better always not less the X idle Threads >>>>>> would >>>>>> be useful :-) >>>>>> >>>>>> Radek >>>>>> >>>>> >>>>> The scenarios above are what is outddated. Fifty requests per >>>>> second isn't any load at all! We have 100's of thousands of >>>>> clients that we have to scale to, and lots more than 50 requests >>>>> per second. >>>>> >>>> What you mean to say is that you need to scale to 100's of >>>> thousands >>>> of >>>> clients on meaningless no-op benchmarks. :) I do know that that >>>> old >>>> SpecJ Java EE benchmarks artifically made EJB pooling important as >>>> process intensive calculation results were cached in these >>>> instances. >>>> But real-world apps don't use this feature/anti-pattern. >>>> >>> >>> I am not talking about a meaningless no-op benchmark, but a >>> benchmark that does lots of work. We don't use meaningless no-op >>> benchmarks on the performance team, with some exception for >>> microbenchmarks that we have carefully crafted that model the >>> interactions for a specific component within the context of how it >>> is actually used for a real application. >>> >>>> Also however crappy it was, I did implement an EJB container at >>>> one >>>> time >>>> in my career. :) I know for a fact that there are a number of >>>> per-request internal support objects that need to be allocated. >>>> Let's >>>> count: >>>> >>>> * The argument array (for reflection) >>>> * Each argument of the method call >>>> * The response object >>>> * Interceptor context object >>>> * The interceptor context attribute map >>>> * EJBContext >>>> * Subject, Principal, role mappings >>>> * Transaction context >>>> * The message object(s) specific to the remote EJB protocol >>>> >>>> Starts to add up huh? I'm probably missing a bunch more. Throw >>>> in >>>> interaction with JPA and you end up with even more per-request >>>> objects >>>> being allocated. You still believe pooling one EJB instance >>>> matters? >>>> >>> >>> See John O'Hara's post which shows our non-meaningless benchmark >>> and the difference that pooling makes vs. non-pooling. It is a >>> dramatic difference to say the least. >> >> There is certainly a correlation identified between the results of >> this benchmark and the use of pooling. However the underlying cause >> of the resulting difference is still unknown. If we knew >> definitively how and why this happens it would help in optimizing >> this further. As an example, if it turned out to be some secondary >> factor, like the throttling aspect of the pool, then eliminating >> these allocations (and others) with a zero-tuning approach, like >> thread local pooling would offer little to no improvement. If >> discovered it is indeed extreme object allocation, and that it came >> from thousands of nested calls in a request, then having a temporary >> per-request thread local cache would dramatically improve the >> results, and be cheap/quick to implement vs a full thread local >> solution. If there is a bug in our code somewhere where under >> certain situations we create hundreds of objects, when we should be >> creating 10s, and the pool covers that up, fixing that bug and >> removing the pool could lead to better results. If it turns out >> there is only 3% extra churn but that extra churn causes a 10x perf >> reduction in GC, then we better understand those limits and >> potentially work with the openjdk team in that area. >> >> >>> >>> This conversation is a perfect example of misinformation that >>> causes us performance and scalability problems within our code >>> bases. >> >> It?s just a surprising result. The pool saves a few allocations, but >> it also has the cost of concurrency usage which can trigger >> blocking, additional barriers, and busy looping on CAS. You also >> still have object churn in the underlying pool data structures that >> occurs per invocation since every invocation is a check-out and a >> check-in (requires a new node object instance), and if the semaphore >> blocks you have additional allocation for the entry in the wait >> queue. You factor in the remaining allocation savings relative to >> other allocations that are required for the invocation, and it >> should be a very small percentage. For that very small percentage to >> lead to several times a difference in performance to me hints at >> other factors being involved. >> > > All logically thought through. At a 15% lower transaction rate than we are doing now, we saw 4 Gigabytes per second of object allocation. We, with Sanne doing most of the work, managed to get that down to 3 Gigabytes per second (I would have loved to get it to 2). Much of that was Hibernate allocations, and of course that was with pooling on. We have not spent the time to pinpoint the exact differences, memory and other, between having pooling on vs. off. Our priority has been continue to scale the workload and fix any problems we see as a result. We have managed to increase the transaction rate another 15% in the last couple of months, but still have another 17+% to go on a single JVM before we start looking at two JVM's for the testing. > > Once we get to our goal, I would love to put this on our list of tasks, so we can get the specific facts, and instead of talking theory, we will no exactly what can and cannot be done, and whether no pooling could ever match pooled. I?m lucky my employer spend us this APM tool... this saved me lot of weeks of work! https://www.youtube.com/watch?v=ATXjpAfF60c#t=190 > > Andy > >> -- >> 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/20140806/86bb7785/attachment-0001.html From anmiller at redhat.com Wed Aug 6 15:12:59 2014 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 6 Aug 2014 15:12:59 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <1F7596F8-5214-43BC-8478-772D96D678E0@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53E0FD09.1000605@redhat.com> <8325926.827.1407268456684.JavaMail.andrig@worklaptop.miller.org> <53E15C5B.3040209@redhat.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> <1F7596F8-5214-43BC-8478-772D96D678E0@redhat.com> Message-ID: <27379313.1299.1407352374649.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Jason Greene" > To: "Bill Burke" > Cc: wildfly-dev at lists.jboss.org > Sent: Wednesday, August 6, 2014 11:37:07 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > On Aug 6, 2014, at 10:30 AM, Bill Burke wrote: > > > What you mean to say is that you need to scale to 100's of > > thousands of > > clients on meaningless no-op benchmarks. :) I do know that that > > old > > SpecJ Java EE benchmarks artifically made EJB pooling important as > > process intensive calculation results were cached in these > > instances. > > But real-world apps don't use this feature/anti-pattern. > > If the benchmark in question is doing that, that would most > definitely explain this. I mean we know the following can perform > poorly without pooling: > > 1. Expensive initialization in @PostConstruct There is no @PreConstruct or @PostContruct methods. > 2. Lazy expensive initialization in a invocation (what you allude to > above) No caching or other lazy initialization is in the stateless session beans. > 3. Expensive initialization in a constructor I'd have to look at the code again, but I don't remember anything like this. > > Large allocations of objects count as expensive initialization. > > -- > 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 anmiller at redhat.com Wed Aug 6 15:14:44 2014 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 6 Aug 2014 15:14:44 -0400 (EDT) Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: References: <53CD3CCE.2030902@imixs.com> <7756203.675.1407336609803.JavaMail.andrig@worklaptop.miller.org> <53E249FE.2010704@redhat.com> <24380467.708.1407340144909.JavaMail.andrig@worklaptop.miller.org> <08F39457-CF7D-4F6F-9343-2251F0EB2562@redhat.com> <32516037.1227.1407345705751.JavaMail.andrig@worklaptop.miller.org> Message-ID: <28264418.1302.1407352479252.JavaMail.andrig@worklaptop.miller.org> ----- Original Message ----- > From: "Jason Greene" > To: "Andrig Miller" > Cc: "Bill Burke" , wildfly-dev at lists.jboss.org > Sent: Wednesday, August 6, 2014 11:48:53 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > On Aug 6, 2014, at 12:21 PM, Andrig Miller > wrote: > > > > > > > ----- Original Message ----- > >> From: "Jason Greene" > >> To: "Andrig Miller" > >> Cc: "Bill Burke" , wildfly-dev at lists.jboss.org > >> Sent: Wednesday, August 6, 2014 11:08:02 AM > >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > >> > >> > >> On Aug 6, 2014, at 10:49 AM, Andrig Miller > >> wrote: > >> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Bill Burke" > >>>> To: wildfly-dev at lists.jboss.org > >>>> Sent: Wednesday, August 6, 2014 9:30:06 AM > >>>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > >>>> > >>> > > > >>> This conversation is a perfect example of misinformation that > >>> causes us performance and scalability problems within our code > >>> bases. > >> > >> It?s just a surprising result. The pool saves a few allocations, > >> but > >> it also has the cost of concurrency usage which can trigger > >> blocking, additional barriers, and busy looping on CAS. You also > >> still have object churn in the underlying pool data structures > >> that > >> occurs per invocation since every invocation is a check-out and a > >> check-in (requires a new node object instance), and if the > >> semaphore > >> blocks you have additional allocation for the entry in the wait > >> queue. You factor in the remaining allocation savings relative to > >> other allocations that are required for the invocation, and it > >> should be a very small percentage. For that very small percentage > >> to > >> lead to several times a difference in performance to me hints at > >> other factors being involved. > >> > > > > All logically thought through. At a 15% lower transaction rate > > than we are doing now, we saw 4 Gigabytes per second of object > > allocation. We, with Sanne doing most of the work, managed to get > > that down to 3 Gigabytes per second (I would have loved to get it > > to 2). Much of that was Hibernate allocations, and of course that > > was with pooling on. We have not spent the time to pinpoint the > > exact differences, memory and other, between having pooling on vs. > > off. Our priority has been continue to scale the workload and fix > > any problems we see as a result. We have managed to increase the > > transaction rate another 15% in the last couple of months, but > > still have another 17+% to go on a single JVM before we start > > looking at two JVM's for the testing. > > > > Once we get to our goal, I would love to put this on our list of > > tasks, so we can get the specific facts, and instead of talking > > theory, we will no exactly what can and cannot be done, and > > whether no pooling could ever match pooled. > > Fair enough, and I certainly didn?t mean to imply that such work > should be your team, I was just speaking generally. In any case, > what I really really would like for us to achieve is a default > implementation that performs generally well on all usage patterns, > with no tuning required. Since we know that initialization can be > costly for some applications usage of SLSB, such an implementation > will definitely require a form of pooling. > No problem, and I think we should do this, we just cannot afford to spend the time right now. We share the same goal. I too would love to have a default configuration, that didn't require tuning that performs and scales really well. > I suspect that a thread local based design with the pooling tied to > worker threads will give us this. Alternatively a shared pool which > is auto-tuned to match might be worth looking into. > > If there is anyone lurking who wishes to contribute in this area > speak up, and I?ll worth with you on it. As doge would say ?Such > Fun. Much Glory? :) > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > From sanne at hibernate.org Thu Aug 7 16:59:24 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 7 Aug 2014 21:59:24 +0100 Subject: [wildfly-dev] Enabling Hibernate Search to all Hibernate/JPA users In-Reply-To: <53E10A10.50902@redhat.com> References: <42030287-3101-4E7E-B4BF-7CB61C7554C9@gmx.net> <53E10A10.50902@redhat.com> Message-ID: Hi Scott, On 5 August 2014 17:45, Scott Marlow wrote: > Thanks for the complements Andrej! :-) > > Sanne, please see in-line below. > > > On 08/05/2014 09:49 AM, Sanne Grinovero wrote: > >> Hi Andrej, >> that's an excellent point. >> >> I also don't want to make it harder for users to play with the latest >> versions we'll be releasing - normally at a higher pace than WildFly. >> > > I'm not sure that you need to sync up with WildFly as much as the > Hibernate ORM project. For example, > > > >> I guess I'll need learn more about writing a subsystem to make sure >> these options are covered. >> > > If Hibernate Search is a part of the Hibernate ORM module, like Envers is, > that could make integration easy enough for Hibernate Search and users that > want to package Hibernate ORM with their application. They either also > include Hibernate Search or not. If applications include Hibernate ORM but > no Hibernate Search, they can't use Hibernate Search. > ?There are no problems for people packaging it as long as they don't enable conflicting modules, my point is that I want to encourage the modules usage to take advantage of its many benefits. Not least, that you don't need to deploy many jars which are already included in the server. ?? > A bigger problem though is that bundling Hibernate Search with the > application, likely means that the application server version of Infinispan > (already configured and ready to work with clustering), will not be usable. > > > Another related issue is that Hibernate 3.x depends on an older version of > Infinispan, so when Hibernate 3.x is used on WildFly, clustering of the > second level cache will not work (even when Hibernate 3.x is used as a > wildfly/modules (static) module). The same will occur with other versions > of Hibernate as well. > > In theory, we could externalize clustering integration to be external to > the Hibernate ORM codebase (in Jipijapa). I've done some experimentation > with that but not too far (more for EclipseLink/OpenJpa 2lc clustering but > we could see some benefit to Hibernate also). > Hibernate Search integrates with the latest versions of ORM and Infinispan, Hibernate 3 is unrelated to this?? The versions of Hibernate Search libraries included in WildFly are released and tested specifically to be fully aligned with the other versions of libraries in WildFly: keeps the modules lean and avoids lots of trouble. No idea why you think I might depend on years old versions :) Also Search doesn't depend on clustering, it's some code of clustering which depends on it (so the other way around), but via this path of the dependency graph you are completely isolated from ORM (the Hibernate Search Engine module does NOT depend on Hibernate ORM). What I'd like is to have this functionality exposed to deployments who need it without them having to reconfigure/enable modules, but I certainly don't want to expose the clustering dependencies as well. I understand now that I need to learn about the subsystems, got it :) Thanks for all the ideas, I'll certainly ping you to learn about subsystem development. Sanne > > > Scott > > >> Thanks all, >> Sanne >> >> On 4 August 2014 20:43, Andrej Golovnin wrote: >> >>> Hi Sanne, >>> >>> I see no reasons to not enable it by default, following the same >>>> activation rules of other Hibernate dependencies: it's very >>>> conservative about not auto-enabling itself when not needed. >>>> >>>> >>> It is OK as long as it will be still possible to bundle Hibernate Search >>> within an application and Hibernate would use the bundled version of >>> Hibernate Search. >>> >>> Not all users want to use Hibernate and Hibernate Search, >>> which are delivered with WildFly. >>> >>> For Hibernate we have a perfect solution developed by Scott, which >>> allows WildFly to use Hibernate packaged inside of an application. >>> At this place a big thanks to Scott for this wonderful solution! It >>> works great! >>> The same should be possible with Hibernate Search. >>> >>> Best regards, >>> Andrej Golovnin >>> >> _______________________________________________ >> >> 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/20140807/ae222c19/attachment.html From asoldano at redhat.com Thu Aug 7 17:29:21 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Thu, 07 Aug 2014 23:29:21 +0200 Subject: [wildfly-dev] Upgrade to Xerces 2.11 ? Message-ID: <53E3EFB1.5000106@redhat.com> Folks, is there a specific reason for WildFly to consume (a patched version of) Xerces 2.9.1 and not move to the latest release (2.11.0) ? Release notes at http://xerces.apache.org/xerces2-j/releases.html . Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From jmesnil at redhat.com Fri Aug 8 07:28:16 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 8 Aug 2014 13:28:16 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <53BC5DA4.6000801@redhat.com> <2D5957F6-277B-4E4F-B3B3-D00E56D44CC3@redhat.com> Message-ID: <8A44769A-AA64-4D57-846F-340F3767C188@redhat.com> On 04 Aug 2014, at 16:27, Jason Greene wrote: POC, I am using a single Map to retain the handler and is separate from the resource tree. >> The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses). >> When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification. >> I.e. the data structure grows with the number of handlers, not with the resources that emits notifications. > > Is this map broken up into path segments to mitigate the o(n) cost? > > e.g.determining if /x=blah/y=foo/z=bar matches x=blah/y=foo/* = 2 O(1) map lookups This is definitely something I need to do to decrease the lookup cost. I?ll have a look if I can reuse the code from our resource registry for that. thanks, jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jmesnil at redhat.com Fri Aug 8 07:30:29 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 8 Aug 2014 13:30:29 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <53DFE0B0.7010405@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <9259A756-7671-47CD-A804-4A2B44C02DFE@redhat.com> <53DFE0B0.7010405@redhat.com> Message-ID: <4E2A306C-5EAE-4607-B5C8-3CF67F0A87D8@redhat.com> On 04 Aug 2014, at 21:36, Brian Stansberry wrote: >> Another thing I?m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward. >> * when a resource is added/removed, the notification is emitted at at is location in the resource trees >> => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate >> => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead > > Are you saying the standard MBeanServerNotification via > JMImplementation:type=MBeanServerDelegate wouldn't work? I think it should. > >> * when an attribute changes, the type of the JMX notification remains attribute-value-written >> => Does it make sense to convert that to JMX AttributeChangeNotification? > > That seems like the intuitive thing to do, and anyone trying to use JMX > to monitor the system would expect such notifications. Why wouldn't we > do that? As a followup, I?ve submitted a PR for the local JMX notifications with your suggestion: * resource-added/removed are converted to MBeanServerNotification emitted by JMImplementation:type=MBeanServerDelegate * attribute-value-written are converted to AttributeChangeNotifcation emitted by the resource itself. jeff [1] https://github.com/wildfly/wildfly-core/pull/82 -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From hrupp at redhat.com Fri Aug 8 07:44:06 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 8 Aug 2014 13:44:06 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <53DFE0B0.7010405@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <9259A756-7671-47CD-A804-4A2B44C02DFE@redhat.com> <53DFE0B0.7010405@redhat.com> Message-ID: <45FC4A7E-BD23-45F5-B84F-699C254874B2@redhat.com> Am 04.08.2014 um 21:36 schrieb Brian Stansberry : >> * when an attribute changes, the type of the JMX notification remains attribute-value-written >> => Does it make sense to convert that to JMX AttributeChangeNotification? > > That seems like the intuitive thing to do, and anyone trying to use JMX > to monitor the system would expect such notifications. Why wouldn't we > do that? +1 There is so much tooling for JMX available that this should be treated as a first class citizen. From frank.langelage at osnanet.de Sat Aug 9 09:15:02 2014 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sat, 09 Aug 2014 15:15:02 +0200 Subject: [wildfly-dev] how to set EjbLogger.ROOT_LOGGER to DEBUG? Message-ID: <53E61ED6.10603@osnanet.de> When running the testsuite, how can I set e.g. EjbLogger.ROOT_LOGGER, which is used in TimerTask and TimerServiceImpl, to DEBUG level? From bbaranow at redhat.com Mon Aug 11 02:10:59 2014 From: bbaranow at redhat.com (Bartosz Baranowski) Date: Mon, 11 Aug 2014 02:10:59 -0400 (EDT) Subject: [wildfly-dev] how to set EjbLogger.ROOT_LOGGER to DEBUG? In-Reply-To: <53E61ED6.10603@osnanet.de> References: <53E61ED6.10603@osnanet.de> Message-ID: <1265890811.8827378.1407737459239.JavaMail.zimbra@redhat.com> Im not sure if there is any better way. I always set up 'org.jboss.as.ejb3' entry (or any other entry I need) in logging subsystem conf prior test execution( in AS binary ). You can probably execute jboss-cli script to do this for jenkins run. This [1] has simple example of such entry set for security. [1] https://community.jboss.org/wiki/JBossAS7Logging ----- Original Message ----- > From: "Frank Langelage" > To: wildfly-dev at lists.jboss.org > Sent: Saturday, August 9, 2014 3:15:02 PM > Subject: [wildfly-dev] how to set EjbLogger.ROOT_LOGGER to DEBUG? > > When running the testsuite, how can I set e.g. EjbLogger.ROOT_LOGGER, > which is used in TimerTask and TimerServiceImpl, to DEBUG level? > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jmesnil at redhat.com Mon Aug 11 06:40:23 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Mon, 11 Aug 2014 12:40:23 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> <53BE9D38.4020607@redhat.com> Message-ID: <8C88A093-5BD4-4495-BABC-1A3E40963E05@redhat.com> On 24 Jul 2014, at 17:43, Toma? Cerar wrote: > I have send PR removing jmx subsystem from core https://github.com/wildfly/wildfly-core/pull/57 > > but to send PR for inclusion to full WildFly repo new release of core is needed as jmx subsystem is using new transformers API we have in core. It?s a minor thing but our jconsole.* scripts still live in wildfly repo. For consistency sake, we should have them in the same repo than the jmx subsystem. No need to do anything if we move back jmx to wildfly soon. But if we decide to keep jmx in wildfly-core, we should move the jconsole scripts there too. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From tomaz.cerar at gmail.com Mon Aug 11 10:11:04 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 11 Aug 2014 16:11:04 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <8C88A093-5BD4-4495-BABC-1A3E40963E05@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> <53BE9D38.4020607@redhat.com> <8C88A093-5BD4-4495-BABC-1A3E40963E05@redhat.com> Message-ID: Just an update on whole JMX subsystem move thingy. It is on halt for now, as there is some work going on that in affects JMX and it is easier to have it in same code repo for time beeing I will be moved once this is complete. -- tomaz On Mon, Aug 11, 2014 at 12:40 PM, Jeff Mesnil wrote: > On 24 Jul 2014, at 17:43, Toma? Cerar wrote: > > > I have send PR removing jmx subsystem from core > https://github.com/wildfly/wildfly-core/pull/57 > > > > but to send PR for inclusion to full WildFly repo new release of core is > needed as jmx subsystem is using new transformers API we have in core. > > It?s a minor thing but our jconsole.* scripts still live in wildfly repo. > For consistency sake, we should have them in the same repo than the jmx > subsystem. > > No need to do anything if we move back jmx to wildfly soon. > But if we decide to keep jmx in wildfly-core, we should move the jconsole > scripts there too. > > jeff > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > 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/20140811/2947c123/attachment.html From jperkins at redhat.com Mon Aug 11 11:38:29 2014 From: jperkins at redhat.com (James R. Perkins) Date: Mon, 11 Aug 2014 08:38:29 -0700 Subject: [wildfly-dev] how to set EjbLogger.ROOT_LOGGER to DEBUG? In-Reply-To: <53E61ED6.10603@osnanet.de> References: <53E61ED6.10603@osnanet.de> Message-ID: <53E8E375.9050505@redhat.com> You could add a @ServerStartup task which just adds the logger and sets it to a level of debug. You might need or want to set the console-handler to debug as well. You can see an example here https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/logging/operations/CustomHandlerTestCase.java#L132. If you need the detailed operations just let me know and I can probably throw it together fairly quickly. On 08/09/2014 06:15 AM, Frank Langelage wrote: > When running the testsuite, how can I set e.g. EjbLogger.ROOT_LOGGER, > which is used in TimerTask and TimerServiceImpl, to DEBUG level? > > _______________________________________________ > 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 lclayton at redhat.com Mon Aug 11 16:09:40 2014 From: lclayton at redhat.com (Liz Clayton) Date: Mon, 11 Aug 2014 16:09:40 -0400 (EDT) Subject: [wildfly-dev] Domain Overview design In-Reply-To: <53E119B9.7040206@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> <660940694.19299854.1406292550805.JavaMail.zimbra@redhat.com> <53D2CECE.8000400@redhat.com> <874726742.21577492.1406659447392.JavaMail.zimbra@redhat.com> <53E119B9.7040206@redhat.com> Message-ID: <491149575.28647130.1407787780373.JavaMail.zimbra@redhat.com> Hi, ----- Original Message ----- > From: "Brian Stansberry" > To: "Liz Clayton" > Cc: wildfly-dev at lists.jboss.org > Sent: Tuesday, August 5, 2014 1:51:53 PM > Subject: Re: [wildfly-dev] Domain Overview design > > On 7/29/14, 1:44 PM, Liz Clayton wrote: > > Hi, > > > > Thanks for answering my questions! > > > > ----- Original Message ----- > >> From: "Brian Stansberry" > >> To: "Liz Clayton" > >> Cc: wildfly-dev at lists.jboss.org > >> Sent: Friday, July 25, 2014 5:40:30 PM > >> Subject: Re: [wildfly-dev] Domain Overview design > >> > > ... > >>> The boxes are irregular on 16 because they were intended to display mini > >>> heatmaps, stacked. And unlike the domain-view version (pg15) where the > >>> size of the box would be driven by # of servers - the mini ones could be > >>> scaled by some other metric (throughput or etc.). But I didn't really > >>> have > >>> that information, so I made the boxes uniformly sized. > >>> > >> > >> I see; so the thought was perhaps the user could choose a scaling factor > >> or something? > > > > I hadn't thought about it being a user selection, but that's an interesting > > idea. > > > > ... > >>>> There's also a similar notion regarding how consistent the server's > >>>> running state is with its persistent configuration. Admins can make > >>>> configuration changes that will not take effect until the server is > >>>> reloaded or restarted. > >>> > >>> Would that directly affect its availability status? > >>> > >> > >> No, it wouldn't. The server goes into this state when the admin makes a > >> config change that the server can't apply to its running services > >> without affecting their ability to handle end-user requests. The server > >> doesn't "just do it", it goes into this state which lets the admin know > >> they need to take an action that *will* temporarily affect availability. > >> > >>>> I'm not sure if those things are well represented on a green-yellow-red > >>>> color continuum because they are somewhat different from server health. > >>>> But they are important pieces of data to visualize. > > > > So there's server health (availability), & server "state", and they are > > both useful bits of high-level info. > > > > Just an FYI -- there was a thread on this list in June about exposing > status information related to graceful shutdown. It's a pretty > convoluted thread, but here's a hopefully useful conclusion point: > > http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html Thanks for sending this pointer! I read through the thread and have a few more questions: - Sounds like there are some terminology issues to reconcile as part of this? - Should these shutdown states be represented in the visualization? If so, do you think they should be represented as: * A graduated scale of availability (shades of yellow/orange), to reflect the various states of suspension or ?out of sync? ness? - or - * A single ?out of sync? (suspended?) state? If that were the case, perhaps ?out of sync? could be represented as an intermediate (yellow/orange) state between green and red. Details about the state could be presented in a hover overlay, with a link to perform the action needed ("restart" for example). Thanks, -Liz > > >>> yes, great to know about. > >>> > >>>> "How does the Alerts tab fit in with the *current* Notification message > >>>> queue?" > >>>> > >>>> Heiko Braun knows better, but I don't see a close fit. The current queue > >>>> isn't really based on any sort of server-push of events. The console > >>>> makes administrative requests and gets responses; if relevant that > >>>> request/response results in stuff in the queue. But anything that > >>>> happens outside of those requests/responses is unknown to the console. > >>> > >>> So there are events happening on the system, that could affect > >>> availability, which will not show up in the message queue? > >>> > >> > >> Absolutely. The console only knows what it specifically asks or the > >> effect of changes it makes, plus a small bit of status information that > >> gets piggy-backed in the response to requests (i.e. that the server is > >> in reload/restart-required state.) But the user's app could be throwing > >> errors all over the place, resources like memory or thread pools could > >> be overtaxed, etc, and the console would have no clue unless it check > >> those specific things. > > > > OK, thanks! > > > > -Liz > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > From hrupp at redhat.com Mon Aug 11 16:41:51 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 11 Aug 2014 22:41:51 +0200 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <491149575.28647130.1407787780373.JavaMail.zimbra@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> <660940694.19299854.1406292550805.JavaMail.zimbra@redhat.com> <53D2CECE.8000400@redhat.com> <874726742.21577492.1406659447392.JavaMail.zimbra@redhat.com> <53E119B9.7040206@redhat.com> <491149575.28647130.1407787780373.JavaMail.zimbra@redhat.com> Message-ID: Am 11.08.2014 um 22:09 schrieb Liz Clayton : >> http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html > > Thanks for sending this pointer! I read through the thread and have a few more questions: > - Sounds like there are some terminology issues to reconcile as part of this? > - Should these shutdown states be represented in the visualization? If so, do you think they should be represented as: > * A graduated scale of availability (shades of yellow/orange), to reflect the various states of suspension or ?out of sync? ness? > - or - > * A single ?out of sync? (suspended?) state? If that were the case, perhaps ?out of sync? could be represented as an intermediate (yellow/orange) state between green and red. Details about the state could be presented in a hover overlay, with a link to perform the action needed ("restart" for example). I think the latter is the better, as both *_REQUIRED states are effectively still RUNNING, but with a configuration which is not the latest. In RHQ we currently have UP/DOWN/UNKNOWN/ADMIN_DOWN (*) and are thinking of extending this to UP: Resource is available and working normally DOWN: Resource is at fault and not working normally MAINTENANCE: There is a scheduled maintenance period, availability may be UP or DOWN MISSING: The resource was recorded in inventory, but does not exist in reality (e.g. was deleted on file system) ADMIN_DOWN/DISABLED: The resource exists, but was disabled by the admin (e.g. a network interface on a 8 port card where only 1 cable is connected) UNKNOWN: Resource state can not be determined and also MIXED for groups of resources. *) e.g. a network interface exists, but has no cable connected on purpose From stuart.w.douglas at gmail.com Mon Aug 11 18:31:41 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 12 Aug 2014 08:31:41 +1000 Subject: [wildfly-dev] how to set EjbLogger.ROOT_LOGGER to DEBUG? In-Reply-To: <53E61ED6.10603@osnanet.de> References: <53E61ED6.10603@osnanet.de> Message-ID: <53E9444D.7010603@gmail.com> There is a facility to set up trace logging when running the test suite. If you do: -Dtrace=org.jboss.as.category1,org.jboss.as.category2 They will be added to standalone.xml as part of the process of setting up the server for the test. Stuart Frank Langelage wrote: > When running the testsuite, how can I set e.g. EjbLogger.ROOT_LOGGER, > which is used in TimerTask and TimerServiceImpl, to DEBUG level? > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From rory.odonnell at oracle.com Tue Aug 12 06:35:55 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Tue, 12 Aug 2014 11:35:55 +0100 Subject: [wildfly-dev] Early Access build for JDK 9 b26 is available on java.net Message-ID: <53E9EE0B.7060908@oracle.com> Hi Guys, Early Access build for JDK 9 b26 is available on java.net. Summary of changes in JDK 9 Build 26 Early Access Build Test Results 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/20140812/5d1c9e0e/attachment.html From tomaz.cerar at gmail.com Wed Aug 13 08:58:37 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 13 Aug 2014 14:58:37 +0200 Subject: [wildfly-dev] Upgrade to Xerces 2.11 ? In-Reply-To: <53E3EFB1.5000106@redhat.com> References: <53E3EFB1.5000106@redhat.com> Message-ID: Yes there is a reason for it, unpatched xerses has problems in modular classloader environment. see https://github.com/jboss/xerces/commits/Xerces-J_2_9_1_jbossas for our changes here. Maybe new version of xerses includes fixes for what we already have but if they don't, we should just take their code and apply our fixes on top of it and release our patched version of 2.11. If you are up for it, check our changes and see if how stuff is now done in upstream. On Thu, Aug 7, 2014 at 11:29 PM, Alessio Soldano wrote: > Folks, > is there a specific reason for WildFly to consume (a patched version of) > Xerces 2.9.1 and not move to the latest release (2.11.0) ? Release notes > at http://xerces.apache.org/xerces2-j/releases.html . > Cheers > Alessio > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > 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/20140813/b5cbc5ea/attachment.html From smarlow at redhat.com Wed Aug 13 15:07:06 2014 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 13 Aug 2014 15:07:06 -0400 Subject: [wildfly-dev] What should the EJB3 StatefulSessionSynchronizationInterceptor.processInvocation() do for transactions that are already committed or rolled back Message-ID: <53EBB75A.1090000@redhat.com> I created WFLY-3731 for a "No transaction is running" ISE [1], that is thrown when org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation() checks if the current transaction is not null and not STATUS_COMMITTED. One obvious fix for WFLY-3731, would be to change StatefulSessionSynchronizationInterceptor.processInvocation() to also check for STATUS_ROLLEDBACK which would help my current case. Doing so might defer clearing the transaction from the current thread, until we later reached EJB container code (not really sure though, if we will clear the ended tx). But, what does it mean exactly for StatefulSessionSynchronizationInterceptor.processInvocation() to see an ended transaction? Seems to me that we missed our chance to register the StatefulSessionSynchronization, so we won't run the StatefulSessionSynchronization.beforeCompletion() and StatefulSessionSynchronization.afterCompletion() methods which I think skips other logic (beforeCompletionMethod/afterCompletionMethod). Currently, it looks like we just continue with the invocation as if there is no current transaction (SFSB level lock appears to be released after the invocation instead of after the transaction ends). Which makes some sense since the transaction already ended. When running the test case [2], I also see a JPA (EE) container level failure as well which is reported as WFLY-3730. Scott [1] http://fpaste.org/125252 show the exception that I see when the transaction times out in a background (tm reaper) thread. [2] test case is pushed to https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut From claudio at claudius.com.br Wed Aug 13 18:54:55 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 13 Aug 2014 19:54:55 -0300 Subject: [wildfly-dev] deployment information In-Reply-To: <53D9FC4F.1080204@redhat.com> References: <53D9FC4F.1080204@redhat.com> Message-ID: Hi, a bit later, was working on other stuff. I looked into ServerDeploymentResourceDefinition and DeploymentResourceDefinition, but was not sure how to register those additional attributes. I put breakpoints there and DeploymentAttributes, but the command below doesn't step into the class /deployment=mysql-connector-java-5.1.26-bin.jar:read-resource(include-runtime=true,include-aliases=true,include-defaults=true,recursive=true) Do you know which class I must look to implement the runtime attribute ? On Thu, Jul 31, 2014 at 5:20 AM, Emmanuel Hugonnet wrote: > Hi, > You would have to register new runtime attributes to the DeploymentResourceDefinition that would read the informations from the > ContentRepository / file depending on how the jar was deployed and if it is exploded or not. > Cheers, > Emmanuel > > > Le 31/07/2014 04:49, Claudio Miranda a ?crit : >> Hi, for any jar deployed, deployment shows >> >> >> /deployment=mysql-connector-java-5.1.26-bin.jar:read-resource(include-runtime=true,include-aliases=true,include-defaults=true,recursive=true) >> { >> "outcome" => "success", >> "result" => { >> "content" => [{"hash" => bytes { >> 0x22, 0x53, 0xb6, 0xad, 0x12, 0x0d, 0x95, 0x46, >> 0xe4, 0x84, 0xe3, 0x3b, 0x54, 0x66, 0xb4, 0xdd, >> 0xa9, 0x02, 0xa8, 0xfd >> }}], >> "enabled" => true, >> "name" => "mysql-connector-java-5.1.26-bin.jar", >> "persistent" => true, >> "runtime-name" => "mysql-connector-java-5.1.26-bin.jar", >> "status" => "OK", >> "subdeployment" => undefined, >> "subsystem" => undefined >> } >> } >> >> I would like to add more information, the timestamp of deployment >> (probably the timestamp of content file on the filesystem), size and >> the hash as in data/content directory. >> >> Tried to look into wildfly-core projects (host-controller, >> deployment-scanner, deployment-repository, wildfly-controller), but >> was unable to find the code that outputs the information to jboss-cli. >> >> I know it uses the instruction below, to request deployment >> information, but what is the project/class invoked for the >> "deployment" command ? >> >> final ModelNode op = >> Util.getEmptyOperation(READ_CHILDREN_RESOURCES_OPERATION, new >> ModelNode()); >> op.get(CHILD_TYPE).set(DEPLOYMENT); >> ModelNode response; >> try { >> response = controllerClient.execute(op); >> >> >> Kind regards >> > -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From smarlow at redhat.com Wed Aug 13 18:58:57 2014 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 13 Aug 2014 18:58:57 -0400 Subject: [wildfly-dev] What should the EJB3 StatefulSessionSynchronizationInterceptor.processInvocation() do for transactions that are already committed or rolled back In-Reply-To: <53EBB75A.1090000@redhat.com> References: <53EBB75A.1090000@redhat.com> Message-ID: <53EBEDB1.8000005@redhat.com> On 08/13/2014 03:07 PM, Scott Marlow wrote: > I created WFLY-3731 for a "No transaction is running" ISE [1], that is > thrown when > org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation() > checks if the current transaction is not null and not STATUS_COMMITTED. > > One obvious fix for WFLY-3731, would be to change > StatefulSessionSynchronizationInterceptor.processInvocation() to also > check for STATUS_ROLLEDBACK which would help my current case. Doing so Checking for STATUS_ROLLEDBACK, helps my test case somewhat. I am still seeing the below mention (WFLY-3730) JPA container failure as a result of the transaction status changing from active, to rolled back, after I called transaction.getStatus() (which returned STATUS_ACTIVE). I'm not quite sure what to do with the "IllegalStateException" that is thrown in either case (EJB or JPA container), since the transaction status can change after StatefulSessionSynchronizationInterceptor checks the status (e.g. in the transaction time out case that my testing is purposely hitting). The other related issue that I'm looking at, is how to better handle transaction time out (to avoid unexpected state or error conditions). I think that we might be missing an opportunity to coordinate the actions that occur when a background thread rolls back a transaction. > might defer clearing the transaction from the current thread, until we > later reached EJB container code (not really sure though, if we will > clear the ended tx). > > But, what does it mean exactly for > StatefulSessionSynchronizationInterceptor.processInvocation() to see an > ended transaction? Seems to me that we missed our chance to register > the StatefulSessionSynchronization, so we won't run the > StatefulSessionSynchronization.beforeCompletion() and > StatefulSessionSynchronization.afterCompletion() methods which I think > skips other logic (beforeCompletionMethod/afterCompletionMethod). > > Currently, it looks like we just continue with the invocation as if > there is no current transaction (SFSB level lock appears to be released > after the invocation instead of after the transaction ends). Which > makes some sense since the transaction already ended. > > When running the test case [2], I also see a JPA (EE) container level > failure as well which is reported as WFLY-3730. > > Scott > > [1] http://fpaste.org/125252 show the exception that I see when the > transaction times out in a background (tm reaper) thread. > > [2] test case is pushed to > https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut > _______________________________________________ > 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 Aug 14 07:58:32 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 14 Aug 2014 12:58:32 +0100 Subject: [wildfly-dev] Can the admin console detect a secure connection? Message-ID: <53ECA468.901@jboss.com> Quick question for the console guys, could it be possible for the admin console to detect is SSL is in use for the connection to the server? Regards, Darran Lofthouse. From tomaz.cerar at gmail.com Thu Aug 14 09:13:07 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 14 Aug 2014 15:13:07 +0200 Subject: [wildfly-dev] Can the admin console detect a secure connection? In-Reply-To: <53ECA468.901@jboss.com> References: <53ECA468.901@jboss.com> Message-ID: I would say that in javascript doing window.location.protocol should give this info. On Thu, Aug 14, 2014 at 1:58 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > Quick question for the console guys, could it be possible for the admin > console to detect is SSL is in use for the connection to the server? > > 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/20140814/fad2f2eb/attachment.html From tomaz.cerar at gmail.com Thu Aug 14 12:31:59 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 14 Aug 2014 18:31:59 +0200 Subject: [wildfly-dev] Proposal for improving handling complex types in CLI Message-ID: Hi guys, there ware some discussions on how we should improve handling complex types of attribute bit better in CLI. For most part that was about Map & List types. After some discussions with few of you I came up with plan / ideas what all options are there for us to improve on. you can see current state of proposed enhancements at https://gist.github.com/ctomc/91055a6f4e7502dcd130 In short, I propose to add set of map-* and list-* global operations and improve :read-attribute & :write-attribute with EL like syntax for reading / updating map, list and generic complex attributes. Let me know what you think about it, especially Console & CLI folks. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140814/de3e592c/attachment-0001.html From smarlow at redhat.com Thu Aug 14 16:11:53 2014 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 14 Aug 2014 16:11:53 -0400 Subject: [wildfly-dev] What should the EJB3 StatefulSessionSynchronizationInterceptor.processInvocation() do for transactions that are already committed or rolled back In-Reply-To: <53EBEDB1.8000005@redhat.com> References: <53EBB75A.1090000@redhat.com> <53EBEDB1.8000005@redhat.com> Message-ID: <53ED1809.9010007@redhat.com> I'll create a PR to also check for (not) STATUS_ROLLEDBACK in StatefulSessionSynchronizationInterceptor.processInvocation. If that doesn't work out, we could check for ACTIVE or MARKED_ROLLBACK. On 08/13/2014 06:58 PM, Scott Marlow wrote: > On 08/13/2014 03:07 PM, Scott Marlow wrote: >> I created WFLY-3731 for a "No transaction is running" ISE [1], that is >> thrown when >> org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation() >> checks if the current transaction is not null and not STATUS_COMMITTED. >> >> One obvious fix for WFLY-3731, would be to change >> StatefulSessionSynchronizationInterceptor.processInvocation() to also >> check for STATUS_ROLLEDBACK which would help my current case. Doing so > > Checking for STATUS_ROLLEDBACK, helps my test case somewhat. I am still > seeing the below mention (WFLY-3730) JPA container failure as a result > of the transaction status changing from active, to rolled back, after I > called transaction.getStatus() (which returned STATUS_ACTIVE). > > I'm not quite sure what to do with the "IllegalStateException" that is > thrown in either case (EJB or JPA container), since the transaction > status can change after StatefulSessionSynchronizationInterceptor checks > the status (e.g. in the transaction time out case that my testing is > purposely hitting). > > The other related issue that I'm looking at, is how to better handle > transaction time out (to avoid unexpected state or error conditions). I > think that we might be missing an opportunity to coordinate the actions > that occur when a background thread rolls back a transaction. > >> might defer clearing the transaction from the current thread, until we >> later reached EJB container code (not really sure though, if we will >> clear the ended tx). >> >> But, what does it mean exactly for >> StatefulSessionSynchronizationInterceptor.processInvocation() to see an >> ended transaction? Seems to me that we missed our chance to register >> the StatefulSessionSynchronization, so we won't run the >> StatefulSessionSynchronization.beforeCompletion() and >> StatefulSessionSynchronization.afterCompletion() methods which I think >> skips other logic (beforeCompletionMethod/afterCompletionMethod). >> >> Currently, it looks like we just continue with the invocation as if >> there is no current transaction (SFSB level lock appears to be released >> after the invocation instead of after the transaction ends). Which >> makes some sense since the transaction already ended. >> >> When running the test case [2], I also see a JPA (EE) container level >> failure as well which is reported as WFLY-3730. >> >> Scott >> >> [1] http://fpaste.org/125252 show the exception that I see when the >> transaction times out in a background (tm reaper) thread. >> >> [2] test case is pushed to >> https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut >> _______________________________________________ >> 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 stuart.w.douglas at gmail.com Thu Aug 14 17:05:16 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 15 Aug 2014 07:05:16 +1000 Subject: [wildfly-dev] What should the EJB3 StatefulSessionSynchronizationInterceptor.processInvocation() do for transactions that are already committed or rolled back In-Reply-To: <53EBEDB1.8000005@redhat.com> References: <53EBB75A.1090000@redhat.com> <53EBEDB1.8000005@redhat.com> Message-ID: <53ED248C.8050108@gmail.com> Scott Marlow wrote: > On 08/13/2014 03:07 PM, Scott Marlow wrote: >> I created WFLY-3731 for a "No transaction is running" ISE [1], that is >> thrown when >> org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation() >> checks if the current transaction is not null and not STATUS_COMMITTED. >> >> One obvious fix for WFLY-3731, would be to change >> StatefulSessionSynchronizationInterceptor.processInvocation() to also >> check for STATUS_ROLLEDBACK which would help my current case. Doing so > > Checking for STATUS_ROLLEDBACK, helps my test case somewhat. I am still > seeing the below mention (WFLY-3730) JPA container failure as a result > of the transaction status changing from active, to rolled back, after I > called transaction.getStatus() (which returned STATUS_ACTIVE). > > I'm not quite sure what to do with the "IllegalStateException" that is > thrown in either case (EJB or JPA container), since the transaction > status can change after StatefulSessionSynchronizationInterceptor checks > the status (e.g. in the transaction time out case that my testing is > purposely hitting). That is a massive edge case and there is not really anything that can be done about it, all you could really do is catch the exception and log it at debug. Stuart > > The other related issue that I'm looking at, is how to better handle > transaction time out (to avoid unexpected state or error conditions). I > think that we might be missing an opportunity to coordinate the actions > that occur when a background thread rolls back a transaction. > >> might defer clearing the transaction from the current thread, until we >> later reached EJB container code (not really sure though, if we will >> clear the ended tx). >> >> But, what does it mean exactly for >> StatefulSessionSynchronizationInterceptor.processInvocation() to see an >> ended transaction? Seems to me that we missed our chance to register >> the StatefulSessionSynchronization, so we won't run the >> StatefulSessionSynchronization.beforeCompletion() and >> StatefulSessionSynchronization.afterCompletion() methods which I think >> skips other logic (beforeCompletionMethod/afterCompletionMethod). >> >> Currently, it looks like we just continue with the invocation as if >> there is no current transaction (SFSB level lock appears to be released >> after the invocation instead of after the transaction ends). Which >> makes some sense since the transaction already ended. >> >> When running the test case [2], I also see a JPA (EE) container level >> failure as well which is reported as WFLY-3730. >> >> Scott >> >> [1] http://fpaste.org/125252 show the exception that I see when the >> transaction times out in a background (tm reaper) thread. >> >> [2] test case is pushed to >> https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut >> _______________________________________________ >> 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 smarlow at redhat.com Thu Aug 14 17:33:07 2014 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 14 Aug 2014 17:33:07 -0400 Subject: [wildfly-dev] What should the EJB3 StatefulSessionSynchronizationInterceptor.processInvocation() do for transactions that are already committed or rolled back In-Reply-To: <53ED248C.8050108@gmail.com> References: <53EBB75A.1090000@redhat.com> <53EBEDB1.8000005@redhat.com> <53ED248C.8050108@gmail.com> Message-ID: <53ED2B13.7040808@redhat.com> On 08/14/2014 05:05 PM, Stuart Douglas wrote: >> >> Checking for STATUS_ROLLEDBACK, helps my test case somewhat. I am still >> seeing the below mention (WFLY-3730) JPA container failure as a result >> of the transaction status changing from active, to rolled back, after I >> called transaction.getStatus() (which returned STATUS_ACTIVE). >> >> I'm not quite sure what to do with the "IllegalStateException" that is >> thrown in either case (EJB or JPA container), since the transaction >> status can change after StatefulSessionSynchronizationInterceptor checks >> the status (e.g. in the transaction time out case that my testing is >> purposely hitting). > > That is a massive edge case and there is not really anything that can be > done about it, all you could really do is catch the exception and log it > at debug. > > Stuart Agreed, I tried one suggestion of catching the ISE and ignoring it if the transaction is ended but that doesn't help, as we fail elsewhere. It is a massive edge case, as we deal with transactions all over the place. Thanks for the response. Scott From jperkins at redhat.com Fri Aug 15 13:01:59 2014 From: jperkins at redhat.com (James R. Perkins) Date: Fri, 15 Aug 2014 10:01:59 -0700 Subject: [wildfly-dev] Switching ARQ to the Launcher API Message-ID: <53EE3D07.1040703@redhat.com> In case anyone missed it there is a new launcher API in WildFly Core (https://github.com/wildfly/wildfly-core/tree/master/launcher). It's already being used for launching a standalone instance and a domain instance in the core test suite. Once there is a new core release I'll also use it in the maven plugin and in the new (barely started) Gradle plugin. I'm also thinking of changing Arquillian in WildFly to use the API rather than the custom process launching it does now. I thought I post this to the list to see if there are any objections or concerns with doing this. -- James R. Perkins JBoss by Red Hat From jason.greene at redhat.com Fri Aug 15 17:32:24 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 15 Aug 2014 16:32:24 -0500 Subject: [wildfly-dev] Switching ARQ to the Launcher API In-Reply-To: <53EE3D07.1040703@redhat.com> References: <53EE3D07.1040703@redhat.com> Message-ID: <50F353D6-8F65-42BC-8B47-A59E8ABFE1A9@redhat.com> On Aug 15, 2014, at 12:01 PM, James R. Perkins wrote: > In case anyone missed it there is a new launcher API in WildFly Core > (https://github.com/wildfly/wildfly-core/tree/master/launcher). It's > already being used for launching a standalone instance and a domain > instance in the core test suite. Once there is a new core release I'll > also use it in the maven plugin and in the new (barely started) Gradle > plugin. > > I'm also thinking of changing Arquillian in WildFly to use the API > rather than the custom process launching it does now. I thought I post > this to the list to see if there are any objections or concerns with > doing this. Sounds good to me. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From hbraun at redhat.com Mon Aug 18 04:01:52 2014 From: hbraun at redhat.com (Heiko Braun) Date: Mon, 18 Aug 2014 10:01:52 +0200 Subject: [wildfly-dev] Proposal for improving handling complex types in CLI In-Reply-To: References: Message-ID: <5FDCDF0E-3871-41DB-B8F4-F70830508C6A@redhat.com> I've already commented on the gist, but for the record here's my point if view: +1 on the custom operation for list/map modifications. But I am against the write-attribute changes and generic complex attributes . IMO we'd better be explicit about complex attributes and limit it to certain usecases: write-attribute is for simple attributes only and yields an error for complex types no support for generic complex attributes. these should become (child) resources themselves introduce an explicit ModelType.LIST and ModelType.MAP (i think the former already exists) /Heiko On 14 Aug 2014, at 18:31, Toma? Cerar wrote: > Hi guys, > > > there ware some discussions on how we should improve handling complex types of attribute bit better in CLI. > For most part that was about Map & List types. > > After some discussions with few of you I came up with plan / ideas what all options are there for us to improve on. > > you can see current state of proposed enhancements at https://gist.github.com/ctomc/91055a6f4e7502dcd130 > > In short, I propose to add set of map-* and list-* global operations and improve :read-attribute & :write-attribute > with EL like syntax for reading / updating map, list and generic complex attributes. > > > Let me know what you think about it, especially Console & CLI folks. > > -- > 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/20140818/88a85d2d/attachment.html From hpehl at redhat.com Mon Aug 18 04:34:57 2014 From: hpehl at redhat.com (Harald Pehl) Date: Mon, 18 Aug 2014 10:34:57 +0200 Subject: [wildfly-dev] Can the admin console detect a secure connection? In-Reply-To: References: <53ECA468.901@jboss.com> Message-ID: Am 14.08.2014 um 15:13 schrieb Toma? Cerar : > I would say that in javascript doing window.location.protocol should give this info. Yes, 'window.location.protocol' will tell whether SSL is used or not. .: Harald > > > On Thu, Aug 14, 2014 at 1:58 PM, Darran Lofthouse wrote: > Quick question for the console guys, could it be possible for the admin > console to detect is SSL is in use for the connection to the server? > > Regards, > Darran Lofthouse. > _______________________________________________ > 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 --- Harald Pehl JBoss by Red Hat http://hpehl.info -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140818/467b8126/attachment-0001.html From tomaz.cerar at gmail.com Mon Aug 18 10:40:28 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 18 Aug 2014 16:40:28 +0200 Subject: [wildfly-dev] Proposal for improving handling complex types in CLI In-Reply-To: <5FDCDF0E-3871-41DB-B8F4-F70830508C6A@redhat.com> References: <5FDCDF0E-3871-41DB-B8F4-F70830508C6A@redhat.com> Message-ID: I will continue discussion here, to have broader audience. Seems most of you are in favor of new map-* list-* operations but not all of you like idea of enhanced read/write-attribute ops. To shed bit of light on this. Complex attributes are here to stay and will always be around. They are/will be used in lesser extend as in original AS7 code but in any case there are here to stay. With extended syntax for write/read-attribute operations I was mostly thinking of simplifying complex attributes read/write Also keeping in mind that every object is also a map and can be addressed and updated as such. having syntax like we could support simple things like this: :write-attribute(name=timeout.unit, value="MINUTES) which we are in dare need of. as current approach for that is :write-attribute(name=timeout, value="{value=10, unit=MINUTES}") where we need to know/change whole object instead of just part of it. I think having this syntax wouldn't change anything for console at all. It would however require some work in CLI area, especially if we would want to have tab completion. Even today there is metadata that tells what complex attributes are and how are they structured, we just don't utilize this info. As it goes for introducing ModelType.MAP I am all in favor of. As it would allow us also few more things when it comes to types of map as currently we only have support for Map where key can only be String. Introducing ModelType.MAP would also require us to introduce few new model metadata constructs such as key-type. I discussed ModelType.MAP with Brian a bit, but he was not big fan as that would require us move all map attributes to use this which would be a big change (100+ attributes) and this would be big compatibility issue. The biggest problem with introducing it is that any object can be used/addressed as map and as such having extra type bit redundant. However we could probably introduce it for WildFly 10 (maybe 9) with jboss-dmr 2.x series. -- tomaz On Mon, Aug 18, 2014 at 10:01 AM, Heiko Braun wrote: > > I've already commented on the gist, but for the record here's my point if > view: > > > +1 on the custom operation for list/map modifications. > > But I am against the write-attribute changes and generic complex > attributes . IMO we'd better be explicit about complex attributes and limit > it to certain usecases: > > - write-attribute is for simple attributes only and yields an error > for complex types > - no support for generic complex attributes. these should become > (child) resources themselves > - introduce an explicit ModelType.LIST and ModelType.MAP (i think the > former already exists) > > > > /Heiko > > > On 14 Aug 2014, at 18:31, Toma? Cerar wrote: > > Hi guys, > > > there ware some discussions on how we should improve handling complex > types of attribute bit better in CLI. > For most part that was about Map & List types. > > After some discussions with few of you I came up with plan / ideas what > all options are there for us to improve on. > > you can see current state of proposed enhancements at > https://gist.github.com/ctomc/91055a6f4e7502dcd130 > > In short, I propose to add set of map-* and list-* global operations and > improve :read-attribute & :write-attribute > with EL like syntax for reading / updating map, list and generic complex > attributes. > > > Let me know what you think about it, especially Console & CLI folks. > > -- > 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/20140818/c98bb044/attachment.html From darran.lofthouse at jboss.com Mon Aug 18 11:20:00 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 18 Aug 2014 16:20:00 +0100 Subject: [wildfly-dev] Can the admin console detect a secure connection? In-Reply-To: References: <53ECA468.901@jboss.com> Message-ID: <53F219A0.5010008@jboss.com> Perfect, thanks guys. On 18/08/14 09:34, Harald Pehl wrote: > > Am 14.08.2014 um 15:13 schrieb Toma? Cerar >: > >> I would say that in javascript doing window.location.protocol should >> give this info. > > Yes, 'window.location.protocol' will tell whether SSL is used or not. > > .: Harald > >> >> >> On Thu, Aug 14, 2014 at 1:58 PM, Darran Lofthouse >> > wrote: >> >> Quick question for the console guys, could it be possible for the >> admin >> console to detect is SSL is in use for the connection to the server? >> >> Regards, >> Darran Lofthouse. >> _______________________________________________ >> 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 > > --- > Harald Pehl > JBoss by Red Hat > http://hpehl.info > From brian.stansberry at redhat.com Mon Aug 18 12:34:28 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 Aug 2014 11:34:28 -0500 Subject: [wildfly-dev] Proposal for improving handling complex types in CLI In-Reply-To: References: <5FDCDF0E-3871-41DB-B8F4-F70830508C6A@redhat.com> Message-ID: <53F22B14.8090205@redhat.com> On 8/18/14, 9:40 AM, Toma? Cerar wrote: > > As it goes for introducing ModelType.MAP I am all in favor of. As it > would allow us also few more things when it comes to > types of map as currently we only have support for Map where > key can only be String. > Introducing ModelType.MAP would also require us to introduce few new > model metadata constructs such as key-type. > Why is a new ModelType needed for this? > I discussed ModelType.MAP with Brian a bit, but he was not big fan as > that would require us move all map attributes to use this > which would be a big change (100+ attributes) and this would be big > compatibility issue. > The biggest problem with introducing it is that any object can be > used/addressed as map and as such having extra type bit redundant. > > However we could probably introduce it for WildFly 10 (maybe 9) with > jboss-dmr 2.x series. > Here's why I'm not a fan: 1) A new ModelType will break every existing client out there. This is a huge problem, and requires an even huger benefit to justify it. 2) We already describe the types of maps at the higher level, so what's the big benefit of pushing something to a lower level? Currently: ModelType attrType = attributeDesc.get("type").getType(); if (attrType == ModelType.OBJECT) { ModelType valueType = attributeDesc.get("value-type").getType(); if (valueType = ModelType.TYPE) { // it' a simple map doStuffWithMap(....); } else { // it's a complex attribute doStuffWithComplexAttribute(....); } } else ... With a ModelType.MAP we get ModelType attrType = attributeDesc.get("type").getType(); if (attrType == ModelType.OBJECT) { // it's a complex attribute doStuffWithComplexAttribute(....); } else if (attrType = ModelType.MAP) { // it' a simple map ModelType valueType = ???; // some new DMR API doStuffWithMap(...); } else ... That's a difference of 2 lines of code in a utility method, and that's assuming that "???; // some new DMR API" is a single line. 3) DMR has a really simple interface -- 4 public classes, ModelNode, ModelType, Property, ValueExpression. To be useful, ModelType.MAP will require some sort of new concept, to express the type of the map value, and perhaps the map key. So a 25% or more increase in the number of types in the public API. Not a big deal by itself but it's a sign that this isn't some minor change. > > -- > tomaz > > > On Mon, Aug 18, 2014 at 10:01 AM, Heiko Braun > wrote: > > > I've already commented on the gist, but for the record here's my > point if view: > > > +1 on the custom operation for list/map modifications. > > But I am against the write-attribute changes and generic complex > attributes . IMO we'd better be explicit about complex attributes > and limit it to certain usecases: > > * write-attribute is for simple attributes only and yields an > error for complex types > * no support for generic complex attributes. these should become > (child) resources themselves > * introduce an explicit ModelType.LIST and ModelType.MAP (i think > the former already exists) > > > > /Heiko > > > On 14 Aug 2014, at 18:31, Toma? Cerar > wrote: > >> Hi guys, >> >> >> there ware some discussions on how we should improve handling >> complex types of attribute bit better in CLI. >> For most part that was about Map & List types. >> >> After some discussions with few of you I came up with plan / ideas >> what all options are there for us to improve on. >> >> you can see current state of proposed enhancements at >> https://gist.github.com/ctomc/91055a6f4e7502dcd130 >> >> In short, I propose to add set of map-* and list-* global >> operations and improve :read-attribute & :write-attribute >> with EL like syntax for reading / updating map, list and generic >> complex attributes. >> >> >> Let me know what you think about it, especially Console & CLI folks. >> >> -- >> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ssilvert at redhat.com Mon Aug 18 13:09:44 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 18 Aug 2014 13:09:44 -0400 Subject: [wildfly-dev] Core and Full out of sync Message-ID: <53F23358.1010909@redhat.com> Build the latest WildFly Core master. In WildFly Full master, change the root pom to use latest core: 1.0.0.Alpha5-SNAPSHOT When you build full, you will get: [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with message: org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile has transitive dependencies: org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile If you exclude the wildfly-launcher dependency, the build gets even uglier. Should these two builds stay in sync somehow? For some features, we need to be able to make changes to both builds at the same time and see them work together. Stan From brian.stansberry at redhat.com Mon Aug 18 13:18:47 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 Aug 2014 12:18:47 -0500 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <53F23358.1010909@redhat.com> References: <53F23358.1010909@redhat.com> Message-ID: <53F23577.1030800@redhat.com> When you build master, include -Dskip-enforce in your args to maven. That turns off the problematic transitive dependency enforcement, which is more trouble than it is worth when dealing with snapshots. When we bring the next release of core in, the master pom will be updated to include the org.wildfly.core:wildfly-launcher dependency. On 8/18/14, 12:09 PM, Stan Silvert wrote: > Build the latest WildFly Core master. > > In WildFly Full master, change the root pom to use latest core: > 1.0.0.Alpha5-SNAPSHOT > > When you build full, you will get: > [WARNING] Rule 0: > org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with > message: > org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT > org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile > has transitive dependencies: > org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile > > If you exclude the wildfly-launcher dependency, the build gets even uglier. > > Should these two builds stay in sync somehow? For some features, we > need to be able to make changes to both builds at the same time and see > them work together. > > Stan > > > > _______________________________________________ > 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 ssilvert at redhat.com Mon Aug 18 13:24:56 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 18 Aug 2014 13:24:56 -0400 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <53F23577.1030800@redhat.com> References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> Message-ID: <53F236E8.7040908@redhat.com> When I do that it gets worse: [ERROR] Failed to execute goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build (create-server) on project wildfly-web-build: Execution create-server of goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build failed: java.lang.RuntimeException: Could not extract resources from artifact org.slf4j:slf4j-api:1 .7.7.jbossorg-1 contents {org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s pec:jar:1.0.0.Final:compile, org.wildfly:wildfly-security=org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, org.wildfly.security:wildfly-security-manager=or g.wildfly.security:wildfly-security-manager:jar:1.0.0.Final:compile, org.jboss.aesh:aesh=org.jboss.aesh:aesh:jar:0.33.12:compile, org.wildfly.core:wildfly-domain-http-int erface:1.0.0.Alpha5-SNAPSHOT=org.wildfly.core:wildfly-domain-http-interface:jar:1.0.0.Alpha5-SNAPSHOT:compile, io.undertow:undertow-core:1.1.0.Beta6=io.undertow:undertow- core:jar:1.1.0.Beta6:compile, org.jboss.sasl:jboss-sasl:1.0.4.Final=org.jboss.sasl:jboss-sasl:jar:1.0.4.Final:compile, org.wildfly:wildfly-security:9.0.0.Alpha1-SNAPSHOT= org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, org.picketbox:picketbox=org.picketbox:picketbox:jar:4.0.21.Beta3:compile, org.fusesource.jansi:jansi=org.f usesource.jansi:jansi:jar:1.9:compile, org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.2.Beta1=org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar :1.1.2.Beta1:compile, org.jboss.logmanager:log4j-jboss-logmanager=org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.0.Final:compile, org.picketbox:picketbox-infinispan: 4.0.21.Beta3=org.picketbox:picketbox-infinispan:jar:4.0.21.Beta3:compile, org.wildfly.core:wildfly-io=org.wildfly.core:wildfly-io:jar:1.0.0.Alpha5-SNAPSHOT:compile, org.j On 8/18/2014 1:18 PM, Brian Stansberry wrote: > When you build master, include -Dskip-enforce in your args to maven. > That turns off the problematic transitive dependency enforcement, which > is more trouble than it is worth when dealing with snapshots. > > When we bring the next release of core in, the master pom will be > updated to include the org.wildfly.core:wildfly-launcher dependency. > > On 8/18/14, 12:09 PM, Stan Silvert wrote: >> Build the latest WildFly Core master. >> >> In WildFly Full master, change the root pom to use latest core: >> 1.0.0.Alpha5-SNAPSHOT >> >> When you build full, you will get: >> [WARNING] Rule 0: >> org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with >> message: >> org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT >> org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile >> has transitive dependencies: >> org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile >> >> If you exclude the wildfly-launcher dependency, the build gets even uglier. >> >> Should these two builds stay in sync somehow? For some features, we >> need to be able to make changes to both builds at the same time and see >> them work together. >> >> Stan >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > From brian.stansberry at redhat.com Mon Aug 18 13:39:48 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 Aug 2014 12:39:48 -0500 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <53F236E8.7040908@redhat.com> References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> <53F236E8.7040908@redhat.com> Message-ID: <53F23A64.70003@redhat.com> Perhaps do a full clean and install? The CI test with the latest WildFly core master is working fine -- I kicked it off when I got your last email and it's through the build and into the testsuite: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WF_WildFlyCoreIntegration&buildId=20129 On 8/18/14, 12:24 PM, Stan Silvert wrote: > When I do that it gets worse: > > [ERROR] Failed to execute goal > org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build > (create-server) on project wildfly-web-build: Execution create-server of > goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build > failed: java.lang.RuntimeException: Could not extract resources from > artifact org.slf4j:slf4j-api:1 > .7.7.jbossorg-1 contents > {org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s > pec:jar:1.0.0.Final:compile, > org.wildfly:wildfly-security=org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, > org.wildfly.security:wildfly-security-manager=or > g.wildfly.security:wildfly-security-manager:jar:1.0.0.Final:compile, > org.jboss.aesh:aesh=org.jboss.aesh:aesh:jar:0.33.12:compile, > org.wildfly.core:wildfly-domain-http-int > erface:1.0.0.Alpha5-SNAPSHOT=org.wildfly.core:wildfly-domain-http-interface:jar:1.0.0.Alpha5-SNAPSHOT:compile, > io.undertow:undertow-core:1.1.0.Beta6=io.undertow:undertow- > core:jar:1.1.0.Beta6:compile, > org.jboss.sasl:jboss-sasl:1.0.4.Final=org.jboss.sasl:jboss-sasl:jar:1.0.4.Final:compile, > org.wildfly:wildfly-security:9.0.0.Alpha1-SNAPSHOT= > org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, > org.picketbox:picketbox=org.picketbox:picketbox:jar:4.0.21.Beta3:compile, org.fusesource.jansi:jansi=org.f > usesource.jansi:jansi:jar:1.9:compile, > org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.2.Beta1=org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar > :1.1.2.Beta1:compile, > org.jboss.logmanager:log4j-jboss-logmanager=org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.0.Final:compile, > org.picketbox:picketbox-infinispan: > 4.0.21.Beta3=org.picketbox:picketbox-infinispan:jar:4.0.21.Beta3:compile, org.wildfly.core:wildfly-io=org.wildfly.core:wildfly-io:jar:1.0.0.Alpha5-SNAPSHOT:compile, > org.j > > On 8/18/2014 1:18 PM, Brian Stansberry wrote: >> When you build master, include -Dskip-enforce in your args to maven. >> That turns off the problematic transitive dependency enforcement, which >> is more trouble than it is worth when dealing with snapshots. >> >> When we bring the next release of core in, the master pom will be >> updated to include the org.wildfly.core:wildfly-launcher dependency. >> >> On 8/18/14, 12:09 PM, Stan Silvert wrote: >>> Build the latest WildFly Core master. >>> >>> In WildFly Full master, change the root pom to use latest core: >>> 1.0.0.Alpha5-SNAPSHOT >>> >>> When you build full, you will get: >>> [WARNING] Rule 0: >>> org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with >>> message: >>> org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT >>> org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile >>> has transitive dependencies: >>> org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile >>> >>> If you exclude the wildfly-launcher dependency, the build gets even uglier. >>> >>> Should these two builds stay in sync somehow? For some features, we >>> need to be able to make changes to both builds at the same time and see >>> them work together. >>> >>> Stan >>> >>> >>> >>> _______________________________________________ >>> 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 ssilvert at redhat.com Mon Aug 18 13:44:05 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 18 Aug 2014 13:44:05 -0400 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <53F23A64.70003@redhat.com> References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> <53F236E8.7040908@redhat.com> <53F23A64.70003@redhat.com> Message-ID: <53F23B65.3010707@redhat.com> No joy. Does that build use the core snapshot? On 8/18/2014 1:39 PM, Brian Stansberry wrote: > Perhaps do a full clean and install? > > The CI test with the latest WildFly core master is working fine -- I > kicked it off when I got your last email and it's through the build and > into the testsuite: > > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WF_WildFlyCoreIntegration&buildId=20129 > > On 8/18/14, 12:24 PM, Stan Silvert wrote: >> When I do that it gets worse: >> >> [ERROR] Failed to execute goal >> org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >> (create-server) on project wildfly-web-build: Execution create-server of >> goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >> failed: java.lang.RuntimeException: Could not extract resources from >> artifact org.slf4j:slf4j-api:1 >> .7.7.jbossorg-1 contents >> {org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s >> pec:jar:1.0.0.Final:compile, >> org.wildfly:wildfly-security=org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >> org.wildfly.security:wildfly-security-manager=or >> g.wildfly.security:wildfly-security-manager:jar:1.0.0.Final:compile, >> org.jboss.aesh:aesh=org.jboss.aesh:aesh:jar:0.33.12:compile, >> org.wildfly.core:wildfly-domain-http-int >> erface:1.0.0.Alpha5-SNAPSHOT=org.wildfly.core:wildfly-domain-http-interface:jar:1.0.0.Alpha5-SNAPSHOT:compile, >> io.undertow:undertow-core:1.1.0.Beta6=io.undertow:undertow- >> core:jar:1.1.0.Beta6:compile, >> org.jboss.sasl:jboss-sasl:1.0.4.Final=org.jboss.sasl:jboss-sasl:jar:1.0.4.Final:compile, >> org.wildfly:wildfly-security:9.0.0.Alpha1-SNAPSHOT= >> org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >> org.picketbox:picketbox=org.picketbox:picketbox:jar:4.0.21.Beta3:compile, org.fusesource.jansi:jansi=org.f >> usesource.jansi:jansi:jar:1.9:compile, >> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.2.Beta1=org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar >> :1.1.2.Beta1:compile, >> org.jboss.logmanager:log4j-jboss-logmanager=org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.0.Final:compile, >> org.picketbox:picketbox-infinispan: >> 4.0.21.Beta3=org.picketbox:picketbox-infinispan:jar:4.0.21.Beta3:compile, org.wildfly.core:wildfly-io=org.wildfly.core:wildfly-io:jar:1.0.0.Alpha5-SNAPSHOT:compile, >> org.j >> >> On 8/18/2014 1:18 PM, Brian Stansberry wrote: >>> When you build master, include -Dskip-enforce in your args to maven. >>> That turns off the problematic transitive dependency enforcement, which >>> is more trouble than it is worth when dealing with snapshots. >>> >>> When we bring the next release of core in, the master pom will be >>> updated to include the org.wildfly.core:wildfly-launcher dependency. >>> >>> On 8/18/14, 12:09 PM, Stan Silvert wrote: >>>> Build the latest WildFly Core master. >>>> >>>> In WildFly Full master, change the root pom to use latest core: >>>> 1.0.0.Alpha5-SNAPSHOT >>>> >>>> When you build full, you will get: >>>> [WARNING] Rule 0: >>>> org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with >>>> message: >>>> org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT >>>> org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile >>>> has transitive dependencies: >>>> org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile >>>> >>>> If you exclude the wildfly-launcher dependency, the build gets even uglier. >>>> >>>> Should these two builds stay in sync somehow? For some features, we >>>> need to be able to make changes to both builds at the same time and see >>>> them work together. >>>> >>>> Stan >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 emartins at redhat.com Mon Aug 18 13:49:28 2014 From: emartins at redhat.com (Eduardo Martins) Date: Mon, 18 Aug 2014 18:49:28 +0100 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <53F23B65.3010707@redhat.com> References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> <53F236E8.7040908@redhat.com> <53F23A64.70003@redhat.com> <53F23B65.3010707@redhat.com> Message-ID: While there is no new core release add the dependency org.wildfly.core wildfly-launcher ${version.org.wildfly.core} to web-build/pom.xml build/pom.xml Then ./build.sh clean -DallTests and rebuild. From ssilvert at redhat.com Mon Aug 18 14:05:37 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 18 Aug 2014 14:05:37 -0400 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> <53F236E8.7040908@redhat.com> <53F23A64.70003@redhat.com> <53F23B65.3010707@redhat.com> Message-ID: <53F24071.1050002@redhat.com> Still not working. I still get: [ERROR] Failed to execute goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build (create-server) on project wildfly-web-build: Execution create-server of goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build failed: java.lang.RuntimeException: Could not extract resources from artifact org.slf4j:slf4j-api:1 .7.7.jbossorg-1 contents {org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s .... Not sure what that's about. On 8/18/2014 1:49 PM, Eduardo Martins wrote: > While there is no new core release add the dependency > > > org.wildfly.core > wildfly-launcher > ${version.org.wildfly.core} > > > to > > web-build/pom.xml > build/pom.xml > > Then > > ./build.sh clean -DallTests > > and rebuild. From brian.stansberry at redhat.com Mon Aug 18 14:28:18 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 Aug 2014 13:28:18 -0500 Subject: [wildfly-dev] Proposal for improving handling complex types in CLI In-Reply-To: <5FDCDF0E-3871-41DB-B8F4-F70830508C6A@redhat.com> References: <5FDCDF0E-3871-41DB-B8F4-F70830508C6A@redhat.com> Message-ID: <53F245C2.4080707@redhat.com> On 8/18/14, 3:01 AM, Heiko Braun wrote: > > I've already commented on the gist, but for the record here's my point > if view: > > > +1 on the custom operation for list/map modifications. > > But I am against the write-attribute changes and generic complex > attributes . IMO we'd better be explicit about complex attributes and > limit it to certain usecases: > > * write-attribute is for simple attributes only and yields an error > for complex types We couldn't do this for compatibility reasons, even if the only complex attributes left were legacy aliases for resources. > * no support for generic complex attributes. these should become > (child) resources themselves I want a resource to have some meaning to an end user as an independent manageable entity. An internal data structure that's simply part of the configuration of some other entity isn't an independently manageable entity. So, a big part of Tomaz's brief in this task is to: a) Drive a better clarification of the boundaries of what an "independent manageable entity" is. In the "squatter resource" discussion for example, David had what looked like a pretty limited take on what was "independent". The other end of the spectrum would be something that should be added/removed from the config as a unit but doesn't actually result in any distinct services. Heiko, you're on this end of the spectrum. I want Tomaz to find and illustrate the cases in between and see if we can come up with some concrete criteria. You guys have already done a great service here with your analysis of the model. b) See where we have complex attributes that really are independent manageable entities, and thus should be resources. (We'll fix these, but that's not part of the immediate requirements/design task.) c) See where we have resources that aren't indepedent and thus should be represented as attributes. (We *may* fix these, but that's not part of the immediate task.) d) If we end up with any complex attributes left (besides simple lists and maps), sort out with your team what API support you need to be able to deal with them. If converting something that's not independent to a child resource makes your life easier because you can use read-resource-definition etc, then we need equivalent ops for complex attributes. In the past we've had some complex attributes that exist primarily to support changing multiple fields in an atomic step. For example "time" and "unit" combined in single attribute.[1] Since the CLI batch command and the underlying composite op let users make multiple changes atomically, this kind of thing is IMHO an insufficient reason for a complex attribute or a child resource. Simple conceptual grouping of related attributes is an insufficient reason for either a child resource or a complex attribute. We'll introduce a new bit of metadata to use for grouping. [1] Side note: I don't think 'time' and 'unit' are very compelling as an complex attribute; I just mention it as an understandable example. > * introduce an explicit ModelType.LIST and ModelType.MAP (i think the > former already exists) > > > > /Heiko > > > On 14 Aug 2014, at 18:31, Toma? Cerar > wrote: > >> Hi guys, >> >> >> there ware some discussions on how we should improve handling complex >> types of attribute bit better in CLI. >> For most part that was about Map & List types. >> >> After some discussions with few of you I came up with plan / ideas >> what all options are there for us to improve on. >> >> you can see current state of proposed enhancements at >> https://gist.github.com/ctomc/91055a6f4e7502dcd130 >> >> In short, I propose to add set of map-* and list-* global operations >> and improve :read-attribute & :write-attribute >> with EL like syntax for reading / updating map, list and generic >> complex attributes. >> >> >> Let me know what you think about it, especially Console & CLI folks. >> >> -- >> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Aug 18 14:33:11 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 Aug 2014 13:33:11 -0500 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <53F23B65.3010707@redhat.com> References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> <53F236E8.7040908@redhat.com> <53F23A64.70003@redhat.com> <53F23B65.3010707@redhat.com> Message-ID: <53F246E7.2040904@redhat.com> On 8/18/14, 12:44 PM, Stan Silvert wrote: > No joy. > Sorry, I don't know what your issue is then. :( > Does that build use the core snapshot? > Yes. It uses the most recent result of [1] if the code that produced that result matches wildfly-core/master's HEAD, and if it doesn't match it runs that job first. [1] http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WildFlyCore_MasterLinux > On 8/18/2014 1:39 PM, Brian Stansberry wrote: >> Perhaps do a full clean and install? >> >> The CI test with the latest WildFly core master is working fine -- I >> kicked it off when I got your last email and it's through the build and >> into the testsuite: >> >> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WF_WildFlyCoreIntegration&buildId=20129 >> >> On 8/18/14, 12:24 PM, Stan Silvert wrote: >>> When I do that it gets worse: >>> >>> [ERROR] Failed to execute goal >>> org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >>> (create-server) on project wildfly-web-build: Execution create-server of >>> goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >>> failed: java.lang.RuntimeException: Could not extract resources from >>> artifact org.slf4j:slf4j-api:1 >>> .7.7.jbossorg-1 contents >>> {org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s >>> pec:jar:1.0.0.Final:compile, >>> org.wildfly:wildfly-security=org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >>> org.wildfly.security:wildfly-security-manager=or >>> g.wildfly.security:wildfly-security-manager:jar:1.0.0.Final:compile, >>> org.jboss.aesh:aesh=org.jboss.aesh:aesh:jar:0.33.12:compile, >>> org.wildfly.core:wildfly-domain-http-int >>> erface:1.0.0.Alpha5-SNAPSHOT=org.wildfly.core:wildfly-domain-http-interface:jar:1.0.0.Alpha5-SNAPSHOT:compile, >>> io.undertow:undertow-core:1.1.0.Beta6=io.undertow:undertow- >>> core:jar:1.1.0.Beta6:compile, >>> org.jboss.sasl:jboss-sasl:1.0.4.Final=org.jboss.sasl:jboss-sasl:jar:1.0.4.Final:compile, >>> org.wildfly:wildfly-security:9.0.0.Alpha1-SNAPSHOT= >>> org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >>> org.picketbox:picketbox=org.picketbox:picketbox:jar:4.0.21.Beta3:compile, org.fusesource.jansi:jansi=org.f >>> usesource.jansi:jansi:jar:1.9:compile, >>> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.2.Beta1=org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar >>> :1.1.2.Beta1:compile, >>> org.jboss.logmanager:log4j-jboss-logmanager=org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.0.Final:compile, >>> org.picketbox:picketbox-infinispan: >>> 4.0.21.Beta3=org.picketbox:picketbox-infinispan:jar:4.0.21.Beta3:compile, org.wildfly.core:wildfly-io=org.wildfly.core:wildfly-io:jar:1.0.0.Alpha5-SNAPSHOT:compile, >>> org.j >>> >>> On 8/18/2014 1:18 PM, Brian Stansberry wrote: >>>> When you build master, include -Dskip-enforce in your args to maven. >>>> That turns off the problematic transitive dependency enforcement, which >>>> is more trouble than it is worth when dealing with snapshots. >>>> >>>> When we bring the next release of core in, the master pom will be >>>> updated to include the org.wildfly.core:wildfly-launcher dependency. >>>> >>>> On 8/18/14, 12:09 PM, Stan Silvert wrote: >>>>> Build the latest WildFly Core master. >>>>> >>>>> In WildFly Full master, change the root pom to use latest core: >>>>> 1.0.0.Alpha5-SNAPSHOT >>>>> >>>>> When you build full, you will get: >>>>> [WARNING] Rule 0: >>>>> org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with >>>>> message: >>>>> org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT >>>>> org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile >>>>> has transitive dependencies: >>>>> org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile >>>>> >>>>> If you exclude the wildfly-launcher dependency, the build gets even uglier. >>>>> >>>>> Should these two builds stay in sync somehow? For some features, we >>>>> need to be able to make changes to both builds at the same time and see >>>>> them work together. >>>>> >>>>> Stan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 emartins at redhat.com Mon Aug 18 15:11:21 2014 From: emartins at redhat.com (Eduardo Martins) Date: Mon, 18 Aug 2014 20:11:21 +0100 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <53F246E7.2040904@redhat.com> References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> <53F236E8.7040908@redhat.com> <53F23A64.70003@redhat.com> <53F23B65.3010707@redhat.com> <53F246E7.2040904@redhat.com> Message-ID: <05AC44A4-9568-468C-A8F9-9A78C60833CB@redhat.com> Perhaps a clean local build of WFLY Core will help? ?E On 18 Aug 2014, at 19:33, Brian Stansberry wrote: > On 8/18/14, 12:44 PM, Stan Silvert wrote: >> No joy. >> > > Sorry, I don't know what your issue is then. :( > >> Does that build use the core snapshot? >> > > Yes. It uses the most recent result of [1] if the code that produced > that result matches wildfly-core/master's HEAD, and if it doesn't match > it runs that job first. > > [1] > http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WildFlyCore_MasterLinux > >> On 8/18/2014 1:39 PM, Brian Stansberry wrote: >>> Perhaps do a full clean and install? >>> >>> The CI test with the latest WildFly core master is working fine -- I >>> kicked it off when I got your last email and it's through the build and >>> into the testsuite: >>> >>> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WF_WildFlyCoreIntegration&buildId=20129 >>> >>> On 8/18/14, 12:24 PM, Stan Silvert wrote: >>>> When I do that it gets worse: >>>> >>>> [ERROR] Failed to execute goal >>>> org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >>>> (create-server) on project wildfly-web-build: Execution create-server of >>>> goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >>>> failed: java.lang.RuntimeException: Could not extract resources from >>>> artifact org.slf4j:slf4j-api:1 >>>> .7.7.jbossorg-1 contents >>>> {org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s >>>> pec:jar:1.0.0.Final:compile, >>>> org.wildfly:wildfly-security=org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >>>> org.wildfly.security:wildfly-security-manager=or >>>> g.wildfly.security:wildfly-security-manager:jar:1.0.0.Final:compile, >>>> org.jboss.aesh:aesh=org.jboss.aesh:aesh:jar:0.33.12:compile, >>>> org.wildfly.core:wildfly-domain-http-int >>>> erface:1.0.0.Alpha5-SNAPSHOT=org.wildfly.core:wildfly-domain-http-interface:jar:1.0.0.Alpha5-SNAPSHOT:compile, >>>> io.undertow:undertow-core:1.1.0.Beta6=io.undertow:undertow- >>>> core:jar:1.1.0.Beta6:compile, >>>> org.jboss.sasl:jboss-sasl:1.0.4.Final=org.jboss.sasl:jboss-sasl:jar:1.0.4.Final:compile, >>>> org.wildfly:wildfly-security:9.0.0.Alpha1-SNAPSHOT= >>>> org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >>>> org.picketbox:picketbox=org.picketbox:picketbox:jar:4.0.21.Beta3:compile, org.fusesource.jansi:jansi=org.f >>>> usesource.jansi:jansi:jar:1.9:compile, >>>> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.2.Beta1=org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar >>>> :1.1.2.Beta1:compile, >>>> org.jboss.logmanager:log4j-jboss-logmanager=org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.0.Final:compile, >>>> org.picketbox:picketbox-infinispan: >>>> 4.0.21.Beta3=org.picketbox:picketbox-infinispan:jar:4.0.21.Beta3:compile, org.wildfly.core:wildfly-io=org.wildfly.core:wildfly-io:jar:1.0.0.Alpha5-SNAPSHOT:compile, >>>> org.j >>>> >>>> On 8/18/2014 1:18 PM, Brian Stansberry wrote: >>>>> When you build master, include -Dskip-enforce in your args to maven. >>>>> That turns off the problematic transitive dependency enforcement, which >>>>> is more trouble than it is worth when dealing with snapshots. >>>>> >>>>> When we bring the next release of core in, the master pom will be >>>>> updated to include the org.wildfly.core:wildfly-launcher dependency. >>>>> >>>>> On 8/18/14, 12:09 PM, Stan Silvert wrote: >>>>>> Build the latest WildFly Core master. >>>>>> >>>>>> In WildFly Full master, change the root pom to use latest core: >>>>>> 1.0.0.Alpha5-SNAPSHOT >>>>>> >>>>>> When you build full, you will get: >>>>>> [WARNING] Rule 0: >>>>>> org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with >>>>>> message: >>>>>> org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT >>>>>> org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile >>>>>> has transitive dependencies: >>>>>> org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile >>>>>> >>>>>> If you exclude the wildfly-launcher dependency, the build gets even uglier. >>>>>> >>>>>> Should these two builds stay in sync somehow? For some features, we >>>>>> need to be able to make changes to both builds at the same time and see >>>>>> them work together. >>>>>> >>>>>> Stan >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > _______________________________________________ > 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/20140818/f5523efe/attachment.html From tomaz.cerar at gmail.com Mon Aug 18 16:04:47 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 18 Aug 2014 22:04:47 +0200 Subject: [wildfly-dev] Proposal for improving handling complex types in CLI In-Reply-To: <53F22B14.8090205@redhat.com> References: <5FDCDF0E-3871-41DB-B8F4-F70830508C6A@redhat.com> <53F22B14.8090205@redhat.com> Message-ID: On Mon, Aug 18, 2014 at 6:34 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > 3) DMR has a really simple interface -- 4 public classes, ModelNode, > ModelType, Property, ValueExpression. To be useful, ModelType.MAP will > require some sort of new concept, to express the type of the map value, > and perhaps the map key. So a 25% or more increase in the number of > types in the public API. Not a big deal by itself but it's a sign that > this isn't some minor change. > Maybe I wasn't clear enough what I meant here. I only implied that we would add ModelType.MAP to jboss-dmr. All other changes would be part of WildFly management, with introducing new model key "key-type" and alike. But I can see what you meant and I am leaning more and more on *not* adding ModelType.MAP. All we need can be handled as part of wildfly mgmt apis to hide as much of "map internal impl" and as long people would use that api it wouldn't matter what impl is. Once we move to annotation driven model most of this will be hidden anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140818/0bd5b5c2/attachment.html From ssilvert at redhat.com Mon Aug 18 18:09:06 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 18 Aug 2014 18:09:06 -0400 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <05AC44A4-9568-468C-A8F9-9A78C60833CB@redhat.com> References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> <53F236E8.7040908@redhat.com> <53F23A64.70003@redhat.com> <53F23B65.3010707@redhat.com> <53F246E7.2040904@redhat.com> <05AC44A4-9568-468C-A8F9-9A78C60833CB@redhat.com> Message-ID: <53F27982.1020907@redhat.com> I found that the problem is with the last commit where Stuart set copy-module-artifacts=false in core-build/server-build.xml. Not sure why that caused me a problem. I'll look closer tomorrow. On 8/18/2014 3:11 PM, Eduardo Martins wrote: > Perhaps a clean local build of WFLY Core will help? > > ---E > > On 18 Aug 2014, at 19:33, Brian Stansberry > > wrote: > >> On 8/18/14, 12:44 PM, Stan Silvert wrote: >>> No joy. >>> >> >> Sorry, I don't know what your issue is then. :( >> >>> Does that build use the core snapshot? >>> >> >> Yes. It uses the most recent result of [1] if the code that produced >> that result matches wildfly-core/master's HEAD, and if it doesn't match >> it runs that job first. >> >> [1] >> http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WildFlyCore_MasterLinux >> >>> On 8/18/2014 1:39 PM, Brian Stansberry wrote: >>>> Perhaps do a full clean and install? >>>> >>>> The CI test with the latest WildFly core master is working fine -- I >>>> kicked it off when I got your last email and it's through the build and >>>> into the testsuite: >>>> >>>> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WF_WildFlyCoreIntegration&buildId=20129 >>>> >>>> On 8/18/14, 12:24 PM, Stan Silvert wrote: >>>>> When I do that it gets worse: >>>>> >>>>> [ERROR] Failed to execute goal >>>>> org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >>>>> (create-server) on project wildfly-web-build: Execution >>>>> create-server of >>>>> goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >>>>> failed: java.lang.RuntimeException: Could not extract resources from >>>>> artifact org.slf4j:slf4j-api:1 >>>>> .7.7.jbossorg-1 contents >>>>> {org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s >>>>> pec:jar:1.0.0.Final:compile, >>>>> org.wildfly:wildfly-security=org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >>>>> org.wildfly.security:wildfly-security-manager=or >>>>> g.wildfly.security:wildfly-security-manager:jar:1.0.0.Final:compile, >>>>> org.jboss.aesh:aesh=org.jboss.aesh:aesh:jar:0.33.12:compile, >>>>> org.wildfly.core:wildfly-domain-http-int >>>>> erface:1.0.0.Alpha5-SNAPSHOT=org.wildfly.core:wildfly-domain-http-interface:jar:1.0.0.Alpha5-SNAPSHOT:compile, >>>>> io.undertow:undertow-core:1.1.0.Beta6=io.undertow:undertow- >>>>> core:jar:1.1.0.Beta6:compile, >>>>> org.jboss.sasl:jboss-sasl:1.0.4.Final=org.jboss.sasl:jboss-sasl:jar:1.0.4.Final:compile, >>>>> org.wildfly:wildfly-security:9.0.0.Alpha1-SNAPSHOT= >>>>> org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >>>>> org.picketbox:picketbox=org.picketbox:picketbox:jar:4.0.21.Beta3:compile, >>>>> org.fusesource.jansi:jansi=org.f >>>>> usesource.jansi:jansi:jar:1.9:compile, >>>>> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.2.Beta1=org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar >>>>> :1.1.2.Beta1:compile, >>>>> org.jboss.logmanager:log4j-jboss-logmanager=org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.0.Final:compile, >>>>> org.picketbox:picketbox-infinispan: >>>>> 4.0.21.Beta3=org.picketbox:picketbox-infinispan:jar:4.0.21.Beta3:compile, >>>>> org.wildfly.core:wildfly-io=org.wildfly.core:wildfly-io:jar:1.0.0.Alpha5-SNAPSHOT:compile, >>>>> org.j >>>>> >>>>> On 8/18/2014 1:18 PM, Brian Stansberry wrote: >>>>>> When you build master, include -Dskip-enforce in your args to maven. >>>>>> That turns off the problematic transitive dependency enforcement, >>>>>> which >>>>>> is more trouble than it is worth when dealing with snapshots. >>>>>> >>>>>> When we bring the next release of core in, the master pom will be >>>>>> updated to include the org.wildfly.core:wildfly-launcher dependency. >>>>>> >>>>>> On 8/18/14, 12:09 PM, Stan Silvert wrote: >>>>>>> Build the latest WildFly Core master. >>>>>>> >>>>>>> In WildFly Full master, change the root pom to use latest core: >>>>>>> 1.0.0.Alpha5-SNAPSHOT >>>>>>> >>>>>>> When you build full, you will get: >>>>>>> [WARNING] Rule 0: >>>>>>> org.apache.maven.plugins.enforcer.BanTransitiveDependencies >>>>>>> failed with >>>>>>> message: >>>>>>> org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT >>>>>>> org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile >>>>>>> has transitive dependencies: >>>>>>> org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile >>>>>>> >>>>>>> If you exclude the wildfly-launcher dependency, the build gets >>>>>>> even uglier. >>>>>>> >>>>>>> Should these two builds stay in sync somehow? For some features, we >>>>>>> need to be able to make changes to both builds at the same time >>>>>>> and see >>>>>>> them work together. >>>>>>> >>>>>>> Stan >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> 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/20140818/7effcdd1/attachment-0001.html From stuart.w.douglas at gmail.com Mon Aug 18 19:45:34 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 19 Aug 2014 09:45:34 +1000 Subject: [wildfly-dev] Core and Full out of sync In-Reply-To: <53F27982.1020907@redhat.com> References: <53F23358.1010909@redhat.com> <53F23577.1030800@redhat.com> <53F236E8.7040908@redhat.com> <53F23A64.70003@redhat.com> <53F23B65.3010707@redhat.com> <53F246E7.2040904@redhat.com> <05AC44A4-9568-468C-A8F9-9A78C60833CB@redhat.com> <53F27982.1020907@redhat.com> Message-ID: <53F2901E.7090509@gmail.com> Looks like this problem occurs when copy-artifacts is false and the core and full versions have different versions of an artifact (in this case slf4j-api). We should be moving to a new iteration of the build tools soon, which should resolve this problem. Stuart Stan Silvert wrote: > I found that the problem is with the last commit where Stuart set > copy-module-artifacts=false in core-build/server-build.xml. > > Not sure why that caused me a problem. I'll look closer tomorrow. > > On 8/18/2014 3:11 PM, Eduardo Martins wrote: >> Perhaps a clean local build of WFLY Core will help? >> >> ?E >> >> On 18 Aug 2014, at 19:33, Brian Stansberry >> > wrote: >> >>> On 8/18/14, 12:44 PM, Stan Silvert wrote: >>>> No joy. >>>> >>> >>> Sorry, I don't know what your issue is then. :( >>> >>>> Does that build use the core snapshot? >>>> >>> >>> Yes. It uses the most recent result of [1] if the code that produced >>> that result matches wildfly-core/master's HEAD, and if it doesn't match >>> it runs that job first. >>> >>> [1] >>> http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WildFlyCore_MasterLinux >>> >>>> On 8/18/2014 1:39 PM, Brian Stansberry wrote: >>>>> Perhaps do a full clean and install? >>>>> >>>>> The CI test with the latest WildFly core master is working fine -- I >>>>> kicked it off when I got your last email and it's through the build and >>>>> into the testsuite: >>>>> >>>>> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WF_WildFlyCoreIntegration&buildId=20129 >>>>> >>>>> >>>>> On 8/18/14, 12:24 PM, Stan Silvert wrote: >>>>>> When I do that it gets worse: >>>>>> >>>>>> [ERROR] Failed to execute goal >>>>>> org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >>>>>> (create-server) on project wildfly-web-build: Execution >>>>>> create-server of >>>>>> goal org.wildfly.core:wildfly-build-plugin:1.0.0.Alpha5-SNAPSHOT:build >>>>>> failed: java.lang.RuntimeException: Could not extract resources from >>>>>> artifact org.slf4j:slf4j-api:1 >>>>>> .7.7.jbossorg-1 contents >>>>>> {org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:1.0.0.Final=org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_s >>>>>> pec:jar:1.0.0.Final:compile, >>>>>> org.wildfly:wildfly-security=org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >>>>>> org.wildfly.security:wildfly-security-manager=or >>>>>> g.wildfly.security:wildfly-security-manager:jar:1.0.0.Final:compile, >>>>>> org.jboss.aesh:aesh=org.jboss.aesh:aesh:jar:0.33.12:compile, >>>>>> org.wildfly.core:wildfly-domain-http-int >>>>>> erface:1.0.0.Alpha5-SNAPSHOT=org.wildfly.core:wildfly-domain-http-interface:jar:1.0.0.Alpha5-SNAPSHOT:compile, >>>>>> io.undertow:undertow-core:1.1.0.Beta6=io.undertow:undertow- >>>>>> core:jar:1.1.0.Beta6:compile, >>>>>> org.jboss.sasl:jboss-sasl:1.0.4.Final=org.jboss.sasl:jboss-sasl:jar:1.0.4.Final:compile, >>>>>> org.wildfly:wildfly-security:9.0.0.Alpha1-SNAPSHOT= >>>>>> org.wildfly:wildfly-security:jar:9.0.0.Alpha1-SNAPSHOT:compile, >>>>>> org.picketbox:picketbox=org.picketbox:picketbox:jar:4.0.21.Beta3:compile, >>>>>> org.fusesource.jansi:jansi=org.f >>>>>> usesource.jansi:jansi:jar:1.9:compile, >>>>>> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:1.1.2.Beta1=org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar >>>>>> :1.1.2.Beta1:compile, >>>>>> org.jboss.logmanager:log4j-jboss-logmanager=org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.0.Final:compile, >>>>>> org.picketbox:picketbox-infinispan: >>>>>> 4.0.21.Beta3=org.picketbox:picketbox-infinispan:jar:4.0.21.Beta3:compile, >>>>>> org.wildfly.core:wildfly-io=org.wildfly.core:wildfly-io:jar:1.0.0.Alpha5-SNAPSHOT:compile, >>>>>> org.j >>>>>> >>>>>> On 8/18/2014 1:18 PM, Brian Stansberry wrote: >>>>>>> When you build master, include -Dskip-enforce in your args to maven. >>>>>>> That turns off the problematic transitive dependency enforcement, >>>>>>> which >>>>>>> is more trouble than it is worth when dealing with snapshots. >>>>>>> >>>>>>> When we bring the next release of core in, the master pom will be >>>>>>> updated to include the org.wildfly.core:wildfly-launcher dependency. >>>>>>> >>>>>>> On 8/18/14, 12:09 PM, Stan Silvert wrote: >>>>>>>> Build the latest WildFly Core master. >>>>>>>> >>>>>>>> In WildFly Full master, change the root pom to use latest core: >>>>>>>> 1.0.0.Alpha5-SNAPSHOT >>>>>>>> >>>>>>>> When you build full, you will get: >>>>>>>> [WARNING] Rule 0: >>>>>>>> org.apache.maven.plugins.enforcer.BanTransitiveDependencies >>>>>>>> failed with >>>>>>>> message: >>>>>>>> org.wildfly:wildfly-web-build:pom:9.0.0.Alpha1-SNAPSHOT >>>>>>>> org.wildfly.core:wildfly-core-build:zip:1.0.0.Alpha5-SNAPSHOT:compile >>>>>>>> has transitive dependencies: >>>>>>>> org.wildfly.core:wildfly-launcher:jar:1.0.0.Alpha5-SNAPSHOT:compile >>>>>>>> >>>>>>>> If you exclude the wildfly-launcher dependency, the build gets >>>>>>>> even uglier. >>>>>>>> >>>>>>>> Should these two builds stay in sync somehow? For some features, we >>>>>>>> need to be able to make changes to both builds at the same time >>>>>>>> and see >>>>>>>> them work together. >>>>>>>> >>>>>>>> Stan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> _______________________________________________ >>> 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 claudio at claudius.com.br Mon Aug 18 23:59:59 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 19 Aug 2014 00:59:59 -0300 Subject: [wildfly-dev] build failure Message-ID: Hi, just updated to latest of wildfly repo, there is a failing test testDeploymentStreamApi(org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase) Time elapsed: 0.44 sec <<< FAILURE! java.lang.AssertionError: expected:<[fa0bc3e6f9cf0ca559f1ff45ffbac6e62c23d556, fa128b7874e7ac4b155aa5f265d4eebbde471d3d]> but was:<[fa0bc3e6f9cf0ca559f1ff45ffbac6e62c23d556]> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:144) at org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeployments(ServerInModuleDeploymentTestCase.java:614) at org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeploymentStreamApi(ServerInModuleDeploymentTestCase.java:93) -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From claudio at claudius.com.br Tue Aug 19 00:37:51 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 19 Aug 2014 01:37:51 -0300 Subject: [wildfly-dev] jboss cli auth failure Message-ID: Hi, just updated to latest in wildfly repo, started standalone and tried to connect with an username, it fails ./jboss-cli.sh -c --user=admin SaslException: Authentication failed: the server presented no authentication mechanisms It works with local authentication ./jboss-cli.sh -c Users admin is added as ./add-user.sh -u admin -p admin123@ Also, it fails with ssl in management interface. Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to https-remoting://localhost:9993. The connection failed at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) at ... Caused by: java.nio.channels.ClosedChannelException I configured ssl as described in [1] 1. http://claudius.com.br/2014/08/protect-wildfly-management-interface/ -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From darran.lofthouse at jboss.com Tue Aug 19 08:33:52 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 19 Aug 2014 13:33:52 +0100 Subject: [wildfly-dev] jboss cli auth failure In-Reply-To: References: Message-ID: <53F34430.8050406@jboss.com> This may be verging more on a forum question issue than a dev list discussion but at the moment I can not reproduce what you are saying for the username/password based authentication issue. Clean builds of both wildfly-core and wildfly and I am able to connect using the CLI with that command once I have defined an admin user. Regards, Darran Lofthouse. On 19/08/14 05:37, Claudio Miranda wrote: > Hi, just updated to latest in wildfly repo, started standalone and > tried to connect with an username, it fails > > ./jboss-cli.sh -c --user=admin > > SaslException: Authentication failed: the server presented no > authentication mechanisms > > It works with local authentication > > ./jboss-cli.sh -c > > Users admin is added as > ./add-user.sh -u admin -p admin123@ > > Also, it fails with ssl in management interface. > > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect > to https-remoting://localhost:9993. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) > at > ... > > Caused by: java.nio.channels.ClosedChannelException > > > I configured ssl as described in [1] > > 1. http://claudius.com.br/2014/08/protect-wildfly-management-interface/ > From lclayton at redhat.com Tue Aug 19 11:26:26 2014 From: lclayton at redhat.com (Liz Clayton) Date: Tue, 19 Aug 2014 11:26:26 -0400 (EDT) Subject: [wildfly-dev] Domain Overview design In-Reply-To: References: Message-ID: <1268951615.33255968.1408461986098.JavaMail.zimbra@redhat.com> Hi, ----- Original Message ----- > From: wildfly-dev-request at lists.jboss.org > To: wildfly-dev at lists.jboss.org ... > ------------------------------ > > Message: 8 > Date: Mon, 11 Aug 2014 22:41:51 +0200 > From: "Heiko W.Rupp" > Subject: Re: [wildfly-dev] Domain Overview design > To: WildFly Dev > Message-ID: > Content-Type: text/plain; charset=windows-1252 > > > Am 11.08.2014 um 22:09 schrieb Liz Clayton : > > >> http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html > > > > Thanks for sending this pointer! I read through the thread and have a few > > more questions: > > - Sounds like there are some terminology issues to reconcile as part of > > this? > > - Should these shutdown states be represented in the visualization? If so, > > do you think they should be represented as: > > * A graduated scale of availability (shades of yellow/orange), to reflect > > the various states of suspension or ?out of sync? ness? > > - or - > > * A single ?out of sync? (suspended?) state? If that were the case, perhaps > > ?out of sync? could be represented as an intermediate (yellow/orange) > > state between green and red. Details about the state could be presented in > > a hover overlay, with a link to perform the action needed ("restart" for > > example). > > I think the latter is the better, as both *_REQUIRED states are effectively > still RUNNING, but with > a configuration which is not the latest. Great to know, thanks! I'll mockup future iterations with the latter, a single out of sync/yellow state. > In RHQ we currently have UP/DOWN/UNKNOWN/ADMIN_DOWN (*) and are thinking of > extending this to > > UP: Resource is available and working normally > DOWN: Resource is at fault and not working normally > MAINTENANCE: There is a scheduled maintenance period, availability may be UP > or DOWN > MISSING: The resource was recorded in inventory, but does not exist in > reality (e.g. was deleted on file system) > ADMIN_DOWN/DISABLED: The resource exists, but was disabled by the admin (e.g. > a network interface on a 8 port card where only 1 cable is connected) > UNKNOWN: Resource state can not be determined > > and also MIXED for groups of resources. > > > *) e.g. a network interface exists, but has no cable connected on purpose Thanks for the list of terms! I'm trying to understand the various terms used for availability monitoring. Best, Liz From stuart.w.douglas at gmail.com Tue Aug 19 22:42:51 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 20 Aug 2014 12:42:51 +1000 Subject: [wildfly-dev] Provisioning and feature packs Message-ID: <53F40B2B.7050605@gmail.com> Hi all, Just a heads up that soon the Wildfly build will be converted over to use feature packs (as talked about in my previous email http://wildfly-development.1055759.n5.nabble.com/Wildfly-provisioning-tools-and-packaging-format-td5714474.html). The relevant PR is https://github.com/wildfly/wildfly-core/pull/116. What this means is that the server will build a 'feature pack' in the core-feature-pack module. This feature pack is then extracted into a complete server in the build and dist directories. The full version of Wildfly will consume this feature pack, rather than a complete server build. Any questions please ask myself or Eduardo (as he has been working on the tooling for this). Stuart From bgeorges at redhat.com Tue Aug 19 22:53:57 2014 From: bgeorges at redhat.com (Bruno Georges) Date: Wed, 20 Aug 2014 14:53:57 +1200 Subject: [wildfly-dev] Provisioning and feature packs In-Reply-To: <53F40B2B.7050605@gmail.com> References: <53F40B2B.7050605@gmail.com> Message-ID: <0C770293-B68A-47E7-B7D5-AD94AF1CC34E@redhat.com> Excellent progress! Thanks to all of you who contributed to this important and critical step to bettering the already fantastic Wildfly server. Best Regards, -- Bruno P. Georges Director, Application Platforms Engineering Red Hat JBoss Middleware c: +65 8218 0964 On 20/08/2014, at 2:42 pm, Stuart Douglas wrote: > Hi all, > > Just a heads up that soon the Wildfly build will be converted over to > use feature packs (as talked about in my previous email > http://wildfly-development.1055759.n5.nabble.com/Wildfly-provisioning-tools-and-packaging-format-td5714474.html). > The relevant PR is https://github.com/wildfly/wildfly-core/pull/116. > > What this means is that the server will build a 'feature pack' in the > core-feature-pack module. This feature pack is then extracted into a > complete server in the build and dist directories. The full version of > Wildfly will consume this feature pack, rather than a complete server > build. > > Any questions please ask myself or Eduardo (as he has been working on > the tooling for this). > > Stuart > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From Juergen.Zimmermann at HS-Karlsruhe.de Wed Aug 20 09:11:39 2014 From: Juergen.Zimmermann at HS-Karlsruhe.de (=?iso-8859-1?Q?J=FCrgen_Zimmermann?=) Date: Wed, 20 Aug 2014 15:11:39 +0200 Subject: [wildfly-dev] Compilation error for wildfly-core 1.0.0.Alpha5 Message-ID: <000a01cfbc78$476f2f00$d64d8d00$@HS-Karlsruhe.de> >From https://github.com/wildfly/wildfly-core/tree/1.0.0.Alpha5 I cloned wildfly-core and tried to compile, but failed (see below). On a windows 8.1 box with JDK 1.8.0_11 I used the command ?mvn clean install?. I also tried to add ?-Dskip-enforce?. Any hint is appreciated. The maven output: [INFO] WildFly: Core Feature Pack ......................... SUCCESS [ 3.355 s] [INFO] WildFly: Build Core ................................ FAILURE [ 2.109 s] [INFO] WildFly Core: Distribution ......................... SKIPPED [INFO] WildFly: Core Model Test Controller Optional ....... SKIPPED [INFO] WildFly: Core Model Tests .......................... SKIPPED [INFO] WildFly: IO Subsystem tests ........................ SKIPPED [INFO] WildFly: Remoting Subsystem Test ................... SKIPPED [INFO] WildFly: Subsystem Test Framework Tests ............ SKIPPED [INFO] WildFly Core Test Suite: Shared .................... SKIPPED [INFO] WildFly: Test Runner ............................... SKIPPED [INFO] WildFly core Test Suite: Aggregator ................ SKIPPED [INFO] WildFly Core Test Suite: Standalone Integration Tests SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 01:44 min [INFO] Finished at: 2014-08-20T14:59:38+02:00 [INFO] Final Memory: 113M/752M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:buil d (server-provisioning) on project wildfly-core-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:buil d failed: java.lang.RuntimeException: java.lang.IllegalStateException: Could not resolve '[subsystem=logging.xml, supplement=null] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :wildfly-core-build -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140820/1acd5cd2/attachment-0001.html From rsearls at redhat.com Wed Aug 20 09:47:52 2014 From: rsearls at redhat.com (Rebecca Searls) Date: Wed, 20 Aug 2014 09:47:52 -0400 (EDT) Subject: [wildfly-dev] arquillian config to test new server element (Question) Message-ID: <1628358401.41843610.1408542472838.JavaMail.zimbra@redhat.com> In Wfly 9 the JBossWS team has added a new server element in jboss-as-webservices_1_3.xsd and added the corresponding code in wfly/webservices. I have added a corresponding test in org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase. Does arquillian need to be changed in some way to access this new feature? My new code in WSAttributesChangesTestCase always fails because it can not find the new server element. I've tried running the test as follows. Both fails the same way. integration-tests.sh install -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode -Dts.noSmoke integration-tests.sh install -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode -Dts.noSmoke -Djboss.dist=$WILDFLY_HOME/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT From tomaz.cerar at gmail.com Wed Aug 20 10:30:55 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 20 Aug 2014 16:30:55 +0200 Subject: [wildfly-dev] Compilation error for wildfly-core 1.0.0.Alpha5 In-Reply-To: <000a01cfbc78$476f2f00$d64d8d00$@HS-Karlsruhe.de> References: <000a01cfbc78$476f2f00$d64d8d00$@HS-Karlsruhe.de> Message-ID: Hi, It looks like new build merged yesterday doesn't work properly on windows. I am looking into fixing it. -- tomaz On Wed, Aug 20, 2014 at 3:11 PM, J?rgen Zimmermann < Juergen.Zimmermann at hs-karlsruhe.de> wrote: > From https://github.com/wildfly/wildfly-core/tree/1.0.0.Alpha5 I cloned > wildfly-core and tried to compile, but failed (see below). On a windows 8.1 > box with JDK 1.8.0_11 I used the command ?mvn clean install?. I also tried > to add ?-Dskip-enforce?. Any hint is appreciated. > > > > The maven output: > > ? > > [INFO] WildFly: Core Feature Pack ......................... SUCCESS [ > 3.355 s] > > [INFO] WildFly: Build Core ................................ FAILURE [ > 2.109 s] > > [INFO] WildFly Core: Distribution ......................... SKIPPED > > [INFO] WildFly: Core Model Test Controller Optional ....... SKIPPED > > [INFO] WildFly: Core Model Tests .......................... SKIPPED > > [INFO] WildFly: IO Subsystem tests ........................ SKIPPED > > [INFO] WildFly: Remoting Subsystem Test ................... SKIPPED > > [INFO] WildFly: Subsystem Test Framework Tests ............ SKIPPED > > [INFO] WildFly Core Test Suite: Shared .................... SKIPPED > > [INFO] WildFly: Test Runner ............................... SKIPPED > > [INFO] WildFly core Test Suite: Aggregator ................ SKIPPED > > [INFO] WildFly Core Test Suite: Standalone Integration Tests SKIPPED > > [INFO] > ------------------------------------------------------------------------ > > [INFO] BUILD FAILURE > > [INFO] > ------------------------------------------------------------------------ > > [INFO] Total time: 01:44 min > > [INFO] Finished at: 2014-08-20T14:59:38+02:00 > > [INFO] Final Memory: 113M/752M > > [INFO] > ------------------------------------------------------------------------ > > [ERROR] Failed to execute goal > org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:build > (server-provisioning) on project wildfly-core-build: Execution > server-provisioning of goal > org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:build > failed: java.lang.RuntimeException: java.lang.IllegalStateException: Could > not resolve '[subsystem=logging.xml, supplement=null] -> [Help 1] > > [ERROR] > > [ERROR] To see the full stack trace of the errors, re-run Maven with the > -e switch. > > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > > [ERROR] > > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException > > [ERROR] > > [ERROR] After correcting the problems, you can resume the build with the > command > > [ERROR] mvn -rf :wildfly-core-build > > _______________________________________________ > 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/20140820/ed0996eb/attachment.html From tomaz.cerar at gmail.com Wed Aug 20 12:11:22 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 20 Aug 2014 18:11:22 +0200 Subject: [wildfly-dev] Compilation error for wildfly-core 1.0.0.Alpha5 In-Reply-To: References: <000a01cfbc78$476f2f00$d64d8d00$@HS-Karlsruhe.de> Message-ID: PR that fixes build plugin sent https://github.com/wildfly/wildfly-build-tools/pull/3 On Wed, Aug 20, 2014 at 4:30 PM, Toma? Cerar wrote: > Hi, > > It looks like new build merged yesterday doesn't work properly on windows. > > I am looking into fixing it. > > -- > tomaz > > > On Wed, Aug 20, 2014 at 3:11 PM, J?rgen Zimmermann < > Juergen.Zimmermann at hs-karlsruhe.de> wrote: > >> From https://github.com/wildfly/wildfly-core/tree/1.0.0.Alpha5 I cloned >> wildfly-core and tried to compile, but failed (see below). On a windows 8.1 >> box with JDK 1.8.0_11 I used the command ?mvn clean install?. I also tried >> to add ?-Dskip-enforce?. Any hint is appreciated. >> >> >> >> The maven output: >> >> ? >> >> [INFO] WildFly: Core Feature Pack ......................... SUCCESS [ >> 3.355 s] >> >> [INFO] WildFly: Build Core ................................ FAILURE [ >> 2.109 s] >> >> [INFO] WildFly Core: Distribution ......................... SKIPPED >> >> [INFO] WildFly: Core Model Test Controller Optional ....... SKIPPED >> >> [INFO] WildFly: Core Model Tests .......................... SKIPPED >> >> [INFO] WildFly: IO Subsystem tests ........................ SKIPPED >> >> [INFO] WildFly: Remoting Subsystem Test ................... SKIPPED >> >> [INFO] WildFly: Subsystem Test Framework Tests ............ SKIPPED >> >> [INFO] WildFly Core Test Suite: Shared .................... SKIPPED >> >> [INFO] WildFly: Test Runner ............................... SKIPPED >> >> [INFO] WildFly core Test Suite: Aggregator ................ SKIPPED >> >> [INFO] WildFly Core Test Suite: Standalone Integration Tests SKIPPED >> >> [INFO] >> ------------------------------------------------------------------------ >> >> [INFO] BUILD FAILURE >> >> [INFO] >> ------------------------------------------------------------------------ >> >> [INFO] Total time: 01:44 min >> >> [INFO] Finished at: 2014-08-20T14:59:38+02:00 >> >> [INFO] Final Memory: 113M/752M >> >> [INFO] >> ------------------------------------------------------------------------ >> >> [ERROR] Failed to execute goal >> org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:build >> (server-provisioning) on project wildfly-core-build: Execution >> server-provisioning of goal >> org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:build >> failed: java.lang.RuntimeException: java.lang.IllegalStateException: Could >> not resolve '[subsystem=logging.xml, supplement=null] -> [Help 1] >> >> [ERROR] >> >> [ERROR] To see the full stack trace of the errors, re-run Maven with the >> -e switch. >> >> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >> >> [ERROR] >> >> [ERROR] For more information about the errors and possible solutions, >> please read the following articles: >> >> [ERROR] [Help 1] >> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException >> >> [ERROR] >> >> [ERROR] After correcting the problems, you can resume the build with the >> command >> >> [ERROR] mvn -rf :wildfly-core-build >> >> _______________________________________________ >> 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/20140820/1dbffc38/attachment.html From darran.lofthouse at jboss.com Wed Aug 20 13:07:01 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 20 Aug 2014 18:07:01 +0100 Subject: [wildfly-dev] arquillian config to test new server element (Question) In-Reply-To: <1628358401.41843610.1408542472838.JavaMail.zimbra@redhat.com> References: <1628358401.41843610.1408542472838.JavaMail.zimbra@redhat.com> Message-ID: <53F4D5B5.1040501@jboss.com> Sorry not answering your question but just to double check, is this schema going into EAP 6? On 20/08/14 14:47, Rebecca Searls wrote: > > In Wfly 9 the JBossWS team has added a new server element in jboss-as-webservices_1_3.xsd > and added the corresponding code in wfly/webservices. I have added a corresponding > test in org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase. > Does arquillian need to be changed in some way to access this new feature? > My new code in WSAttributesChangesTestCase always fails because it can not find > the new server element. I've tried running the test as follows. Both fails the > same way. > > integration-tests.sh install -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode -Dts.noSmoke > > integration-tests.sh install -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode -Dts.noSmoke -Djboss.dist=$WILDFLY_HOME/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From rsearls at redhat.com Wed Aug 20 14:10:10 2014 From: rsearls at redhat.com (Rebecca Searls) Date: Wed, 20 Aug 2014 14:10:10 -0400 (EDT) Subject: [wildfly-dev] arquillian config to test new server element (Question) In-Reply-To: <53F4D5B5.1040501@jboss.com> References: <1628358401.41843610.1408542472838.JavaMail.zimbra@redhat.com> <53F4D5B5.1040501@jboss.com> Message-ID: <668964488.42112001.1408558210137.JavaMail.zimbra@redhat.com> No only wfly 9 onward. ----- Original Message ----- > From: "Darran Lofthouse" > To: wildfly-dev at lists.jboss.org > Sent: Wednesday, August 20, 2014 1:07:01 PM > Subject: Re: [wildfly-dev] arquillian config to test new server element (Question) > > Sorry not answering your question but just to double check, is this > schema going into EAP 6? > > On 20/08/14 14:47, Rebecca Searls wrote: > > > > In Wfly 9 the JBossWS team has added a new server element in > > jboss-as-webservices_1_3.xsd > > and added the corresponding code in wfly/webservices. I have added a > > corresponding > > test in org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase. > > Does arquillian need to be changed in some way to access this new feature? > > My new code in WSAttributesChangesTestCase always fails because it can not > > find > > the new server element. I've tried running the test as follows. Both > > fails the > > same way. > > > > integration-tests.sh install > > -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode > > -Dts.noSmoke > > > > integration-tests.sh install > > -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode > > -Dts.noSmoke > > -Djboss.dist=$WILDFLY_HOME/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT > > > > > > _______________________________________________ > > 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 Wed Aug 20 14:29:05 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 20 Aug 2014 13:29:05 -0500 Subject: [wildfly-dev] arquillian config to test new server element (Question) In-Reply-To: <1628358401.41843610.1408542472838.JavaMail.zimbra@redhat.com> References: <1628358401.41843610.1408542472838.JavaMail.zimbra@redhat.com> Message-ID: <53F4E8F1.20106@redhat.com> No, there shouldn't be any change needed in arquillian to handle some change in a subsystem's management API. On 8/20/14, 8:47 AM, Rebecca Searls wrote: > > In Wfly 9 the JBossWS team has added a new server element in jboss-as-webservices_1_3.xsd > and added the corresponding code in wfly/webservices. I have added a corresponding > test in org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase. > Does arquillian need to be changed in some way to access this new feature? > My new code in WSAttributesChangesTestCase always fails because it can not find > the new server element. I've tried running the test as follows. Both fails the > same way. > > integration-tests.sh install -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode -Dts.noSmoke > > integration-tests.sh install -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode -Dts.noSmoke -Djboss.dist=$WILDFLY_HOME/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT > > > _______________________________________________ > 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 brian.stansberry at redhat.com Wed Aug 20 14:31:58 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 20 Aug 2014 13:31:58 -0500 Subject: [wildfly-dev] arquillian config to test new server element (Question) In-Reply-To: <668964488.42112001.1408558210137.JavaMail.zimbra@redhat.com> References: <1628358401.41843610.1408542472838.JavaMail.zimbra@redhat.com> <53F4D5B5.1040501@jboss.com> <668964488.42112001.1408558210137.JavaMail.zimbra@redhat.com> Message-ID: <53F4E99E.6080200@redhat.com> The xsd should be version 2_0 then, not 1_3. The 1_x series should be reserved for EAP 6. Otherwise if EAP needs a schema update but can't pull in everything in the current WildFly schema, we're stuck. Management API versions and schemas should increment the major version every time WildFly does. On 8/20/14, 1:10 PM, Rebecca Searls wrote: > No only wfly 9 onward. > > ----- Original Message ----- >> From: "Darran Lofthouse" >> To: wildfly-dev at lists.jboss.org >> Sent: Wednesday, August 20, 2014 1:07:01 PM >> Subject: Re: [wildfly-dev] arquillian config to test new server element (Question) >> >> Sorry not answering your question but just to double check, is this >> schema going into EAP 6? >> >> On 20/08/14 14:47, Rebecca Searls wrote: >>> >>> In Wfly 9 the JBossWS team has added a new server element in >>> jboss-as-webservices_1_3.xsd >>> and added the corresponding code in wfly/webservices. I have added a >>> corresponding >>> test in org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase. >>> Does arquillian need to be changed in some way to access this new feature? >>> My new code in WSAttributesChangesTestCase always fails because it can not >>> find >>> the new server element. I've tried running the test as follows. Both >>> fails the >>> same way. >>> >>> integration-tests.sh install >>> -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode >>> -Dts.noSmoke >>> >>> integration-tests.sh install >>> -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode >>> -Dts.noSmoke >>> -Djboss.dist=$WILDFLY_HOME/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT >>> >>> >>> _______________________________________________ >>> 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 arun.gupta at gmail.com Wed Aug 20 17:23:50 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 20 Aug 2014 14:23:50 -0700 Subject: [wildfly-dev] WildFly CI build is broken Message-ID: WildFly CI at https://ci.jboss.org/hudson/job/WildFly-latest-master/ is stamped Aug 6th. Can somebody please fix it ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From arun.gupta at gmail.com Wed Aug 20 17:48:36 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 20 Aug 2014 14:48:36 -0700 Subject: [wildfly-dev] Install WildFly 9 failing to start Message-ID: Built the trunk using "mvn package" Unzipped "target/wildfly-9.0.0.Alpha1-SNAPSHOT" Started WildFly as "bin/standalone.sh" Got the following error: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 14:41:31,218 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.4.Final 14:41:31,681 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final 14:41:31,748 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly 1.0.0.Alpha5 "Kenny" starting 14:41:32,057 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.as.server.ServerService.boot(ServerService.java:343) [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:260) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.jboss.as.clustering.infinispan at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:155) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:435) [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] ... 3 more Caused by: java.util.concurrent.ExecutionException: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module at java.util.concurrent.FutureTask.report(FutureTask.java:122) [rt.jar:1.8.0] at java.util.concurrent.FutureTask.get(FutureTask.java:192) [rt.jar:1.8.0] at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:147) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] ... 9 more Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:196) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:69) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:127) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:124) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /Users/arungupta/tools/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/module.xml at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:154) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:131) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:154) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:148) [jboss-modules.jar:1.3.4.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:148) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:456) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:359) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:306) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238) [jboss-modules.jar:1.3.4.Final] at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178) [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] ... 8 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve artifact 'org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT' (position: END_TAG seen ...org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT"/>... @35:91) at org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:752) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:647) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:445) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:264) [jboss-modules.jar:1.3.4.Final] at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:152) [jboss-modules.jar:1.3.4.Final] ... 18 more 14:41:32,061 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. 14:41:32,073 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly 1.0.0.Alpha5 "Kenny" stopped in 7ms Do I need to install feature-pack/target/wildfly-9.0.0.Alpha1-SNAPSHOT.zip ? How ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From tomaz.cerar at gmail.com Wed Aug 20 18:22:01 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 21 Aug 2014 00:22:01 +0200 Subject: [wildfly-dev] WildFly CI build is broken In-Reply-To: References: Message-ID: Yes it is a known problem. It occurred when internal jenkins instance was updated and is not compatible with public one anymore. Jenkins CI guys are aware of the problem and are working on it. see ticket 311347 for more -- tomaz On Wed, Aug 20, 2014 at 11:23 PM, Arun Gupta wrote: > WildFly CI at https://ci.jboss.org/hudson/job/WildFly-latest-master/ > is stamped Aug 6th. > > Can somebody please fix it ? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140821/e16a4abb/attachment.html From arun.gupta at gmail.com Wed Aug 20 18:27:54 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 20 Aug 2014 15:27:54 -0700 Subject: [wildfly-dev] WildFly CI build is broken In-Reply-To: References: Message-ID: Got it, thanks! BTW, just pushed out my blog on WildFly 9 at: http://blog.arungupta.me/2014/08/wildfly9-feature-getting-started/ Are there references to discussions on proposed features ? Arun On Wed, Aug 20, 2014 at 3:22 PM, Toma? Cerar wrote: > Yes it is a known problem. > > It occurred when internal jenkins instance was updated and is not compatible > with public one anymore. > > Jenkins CI guys are aware of the problem and are working on it. > see ticket 311347 for more > > -- > tomaz > > > On Wed, Aug 20, 2014 at 11:23 PM, Arun Gupta wrote: >> >> WildFly CI at https://ci.jboss.org/hudson/job/WildFly-latest-master/ >> is stamped Aug 6th. >> >> Can somebody please fix it ? >> >> 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 tomaz.cerar at gmail.com Wed Aug 20 18:31:39 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 21 Aug 2014 00:31:39 +0200 Subject: [wildfly-dev] Install WildFly 9 failing to start In-Reply-To: References: Message-ID: use dist/target/ not build/target for time being. how do your maven settings.xml look like? and where do you have it? in user.home/.m2/settings.xml? in M2_HOME/conf/settings.xml? or even somewhere else? -- tomaz On Wed, Aug 20, 2014 at 11:48 PM, Arun Gupta wrote: > Built the trunk using "mvn package" > Unzipped "target/wildfly-9.0.0.Alpha1-SNAPSHOT" > Started WildFly as "bin/standalone.sh" > Got the following error: > > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option > MaxPermSize=256m; support was removed in 8.0 > > 14:41:31,218 INFO [org.jboss.modules] (main) JBoss Modules version > 1.3.4.Final > > 14:41:31,681 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final > > 14:41:31,748 INFO [org.jboss.as] (MSC service thread 1-5) > WFLYSRV0049: WildFly 1.0.0.Alpha5 "Kenny" starting > > 14:41:32,057 ERROR [org.jboss.as.server] (Controller Boot Thread) > WFLYSRV0055: Caught exception during boot: > org.jboss.as.controller.persistence.ConfigurationPersistenceException: > WFLYCTL0085: Failed to parse configuration > > at > org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at org.jboss.as.server.ServerService.boot(ServerService.java:343) > [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at > org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:260) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > > Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to > load module org.jboss.as.clustering.infinispan > > at > org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:155) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at > org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:435) > [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at > org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) > [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at > org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) > [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > [staxmapper-1.1.0.Final.jar:1.1.0.Final] > > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > [staxmapper-1.1.0.Final.jar:1.1.0.Final] > > at > org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > ... 3 more > > Caused by: java.util.concurrent.ExecutionException: > javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load > module > > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > [rt.jar:1.8.0] > > at java.util.concurrent.FutureTask.get(FutureTask.java:192) [rt.jar:1.8.0] > > at > org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:147) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > ... 9 more > > Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to > load module > > at > org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:196) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at > org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:69) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at > org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:127) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at > org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:124) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0] > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [rt.jar:1.8.0] > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [rt.jar:1.8.0] > > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > > Caused by: org.jboss.modules.ModuleLoadException: Error loading module > from > /Users/arungupta/tools/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/module.xml > > at > org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:154) > [jboss-modules.jar:1.3.4.Final] > > at > org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:131) > [jboss-modules.jar:1.3.4.Final] > > at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:154) > [jboss-modules.jar:1.3.4.Final] > > at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:148) > [jboss-modules.jar:1.3.4.Final] > > at java.security.AccessController.doPrivileged(Native Method) > [rt.jar:1.8.0] > > at > org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:148) > [jboss-modules.jar:1.3.4.Final] > > at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:456) > [jboss-modules.jar:1.3.4.Final] > > at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:359) > [jboss-modules.jar:1.3.4.Final] > > at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:306) > [jboss-modules.jar:1.3.4.Final] > > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238) > [jboss-modules.jar:1.3.4.Final] > > at > org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178) > [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > > ... 8 more > > Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to > resolve artifact > 'org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT' > (position: END_TAG seen > ...org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT"/>... > @35:91) > > at > org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:752) > [jboss-modules.jar:1.3.4.Final] > > at > org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:647) > [jboss-modules.jar:1.3.4.Final] > > at > org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:445) > [jboss-modules.jar:1.3.4.Final] > > at > org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:264) > [jboss-modules.jar:1.3.4.Final] > > at > org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:152) > [jboss-modules.jar:1.3.4.Final] > > ... 18 more > > > 14:41:32,061 FATAL [org.jboss.as.server] (Controller Boot Thread) > WFLYSRV0056: Server boot has failed in an unrecoverable manner; > exiting. See previous messages for details. > > 14:41:32,073 INFO [org.jboss.as] (MSC service thread 1-6) > WFLYSRV0050: WildFly 1.0.0.Alpha5 "Kenny" stopped in 7ms > > > Do I need to install > feature-pack/target/wildfly-9.0.0.Alpha1-SNAPSHOT.zip ? How ? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140821/eb28a8b2/attachment-0001.html From arun.gupta at gmail.com Wed Aug 20 18:45:34 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 20 Aug 2014 15:45:34 -0700 Subject: [wildfly-dev] Install WildFly 9 failing to start In-Reply-To: References: Message-ID: "install" builds the correct distribution. Zip bundle built using "package" was giving this error. On Wed, Aug 20, 2014 at 3:31 PM, Toma? Cerar wrote: > use dist/target/ not build/target for time being. Updated the blog as well > > how do your maven settings.xml look like? No settings.xml > > and where do you have it? in user.home/.m2/settings.xml? Nothing there > in M2_HOME/conf/settings.xml? No conf in M2_HOME > or even somewhere else? Nope Arun > > -- > tomaz > > > > On Wed, Aug 20, 2014 at 11:48 PM, Arun Gupta wrote: >> >> Built the trunk using "mvn package" >> Unzipped "target/wildfly-9.0.0.Alpha1-SNAPSHOT" >> Started WildFly as "bin/standalone.sh" >> Got the following error: >> >> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option >> MaxPermSize=256m; support was removed in 8.0 >> >> 14:41:31,218 INFO [org.jboss.modules] (main) JBoss Modules version >> 1.3.4.Final >> >> 14:41:31,681 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final >> >> 14:41:31,748 INFO [org.jboss.as] (MSC service thread 1-5) >> WFLYSRV0049: WildFly 1.0.0.Alpha5 "Kenny" starting >> >> 14:41:32,057 ERROR [org.jboss.as.server] (Controller Boot Thread) >> WFLYSRV0055: Caught exception during boot: >> org.jboss.as.controller.persistence.ConfigurationPersistenceException: >> WFLYCTL0085: Failed to parse configuration >> >> at >> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at org.jboss.as.server.ServerService.boot(ServerService.java:343) >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at >> org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:260) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] >> >> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to >> load module org.jboss.as.clustering.infinispan >> >> at >> org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:155) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at >> org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:435) >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at >> org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at >> org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at >> org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) >> [staxmapper-1.1.0.Final.jar:1.1.0.Final] >> >> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) >> [staxmapper-1.1.0.Final.jar:1.1.0.Final] >> >> at >> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> ... 3 more >> >> Caused by: java.util.concurrent.ExecutionException: >> javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load >> module >> >> at java.util.concurrent.FutureTask.report(FutureTask.java:122) >> [rt.jar:1.8.0] >> >> at java.util.concurrent.FutureTask.get(FutureTask.java:192) [rt.jar:1.8.0] >> >> at >> org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:147) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> ... 9 more >> >> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to >> load module >> >> at >> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:196) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at >> org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:69) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at >> org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:127) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at >> org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:124) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0] >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> [rt.jar:1.8.0] >> >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> [rt.jar:1.8.0] >> >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] >> >> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >> >> Caused by: org.jboss.modules.ModuleLoadException: Error loading module >> from >> /Users/arungupta/tools/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/module.xml >> >> at >> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:154) >> [jboss-modules.jar:1.3.4.Final] >> >> at >> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:131) >> [jboss-modules.jar:1.3.4.Final] >> >> at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:154) >> [jboss-modules.jar:1.3.4.Final] >> >> at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:148) >> [jboss-modules.jar:1.3.4.Final] >> >> at java.security.AccessController.doPrivileged(Native Method) >> [rt.jar:1.8.0] >> >> at >> org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:148) >> [jboss-modules.jar:1.3.4.Final] >> >> at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:456) >> [jboss-modules.jar:1.3.4.Final] >> >> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:359) >> [jboss-modules.jar:1.3.4.Final] >> >> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:306) >> [jboss-modules.jar:1.3.4.Final] >> >> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238) >> [jboss-modules.jar:1.3.4.Final] >> >> at >> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178) >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> ... 8 more >> >> Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to >> resolve artifact >> 'org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT' >> (position: END_TAG seen >> ...org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT"/>... >> @35:91) >> >> at >> org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:752) >> [jboss-modules.jar:1.3.4.Final] >> >> at >> org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:647) >> [jboss-modules.jar:1.3.4.Final] >> >> at >> org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:445) >> [jboss-modules.jar:1.3.4.Final] >> >> at >> org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:264) >> [jboss-modules.jar:1.3.4.Final] >> >> at >> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:152) >> [jboss-modules.jar:1.3.4.Final] >> >> ... 18 more >> >> >> 14:41:32,061 FATAL [org.jboss.as.server] (Controller Boot Thread) >> WFLYSRV0056: Server boot has failed in an unrecoverable manner; >> exiting. See previous messages for details. >> >> 14:41:32,073 INFO [org.jboss.as] (MSC service thread 1-6) >> WFLYSRV0050: WildFly 1.0.0.Alpha5 "Kenny" stopped in 7ms >> >> >> Do I need to install >> feature-pack/target/wildfly-9.0.0.Alpha1-SNAPSHOT.zip ? How ? >> >> 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 tomaz.cerar at gmail.com Wed Aug 20 18:51:26 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 21 Aug 2014 00:51:26 +0200 Subject: [wildfly-dev] Install WildFly 9 failing to start In-Reply-To: References: Message-ID: Ah nevermind, fix that fixes your problem is not part of jboss-modules 1.3.4 yet. anyhow, we have on our radar. On Thu, Aug 21, 2014 at 12:45 AM, Arun Gupta wrote: > "install" builds the correct distribution. Zip bundle built using > "package" was giving this error. > > On Wed, Aug 20, 2014 at 3:31 PM, Toma? Cerar > wrote: > > use dist/target/ not build/target for time being. > Updated the blog as well > > > > > how do your maven settings.xml look like? > No settings.xml > > > > > and where do you have it? in user.home/.m2/settings.xml? > Nothing there > > > in M2_HOME/conf/settings.xml? > No conf in M2_HOME > > > or even somewhere else? > Nope > > Arun > > > > > -- > > tomaz > > > > > > > > On Wed, Aug 20, 2014 at 11:48 PM, Arun Gupta > wrote: > >> > >> Built the trunk using "mvn package" > >> Unzipped "target/wildfly-9.0.0.Alpha1-SNAPSHOT" > >> Started WildFly as "bin/standalone.sh" > >> Got the following error: > >> > >> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option > >> MaxPermSize=256m; support was removed in 8.0 > >> > >> 14:41:31,218 INFO [org.jboss.modules] (main) JBoss Modules version > >> 1.3.4.Final > >> > >> 14:41:31,681 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final > >> > >> 14:41:31,748 INFO [org.jboss.as] (MSC service thread 1-5) > >> WFLYSRV0049: WildFly 1.0.0.Alpha5 "Kenny" starting > >> > >> 14:41:32,057 ERROR [org.jboss.as.server] (Controller Boot Thread) > >> WFLYSRV0055: Caught exception during boot: > >> org.jboss.as.controller.persistence.ConfigurationPersistenceException: > >> WFLYCTL0085: Failed to parse configuration > >> > >> at > >> > org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at org.jboss.as.server.ServerService.boot(ServerService.java:343) > >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at > >> > org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:260) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > >> > >> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to > >> load module org.jboss.as.clustering.infinispan > >> > >> at > >> > org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:155) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at > >> > org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:435) > >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at > >> > org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) > >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at > >> > org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) > >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at > >> org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > >> [staxmapper-1.1.0.Final.jar:1.1.0.Final] > >> > >> at > org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > >> [staxmapper-1.1.0.Final.jar:1.1.0.Final] > >> > >> at > >> > org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> ... 3 more > >> > >> Caused by: java.util.concurrent.ExecutionException: > >> javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load > >> module > >> > >> at java.util.concurrent.FutureTask.report(FutureTask.java:122) > >> [rt.jar:1.8.0] > >> > >> at java.util.concurrent.FutureTask.get(FutureTask.java:192) > [rt.jar:1.8.0] > >> > >> at > >> > org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:147) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> ... 9 more > >> > >> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to > >> load module > >> > >> at > >> > org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:196) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at > >> > org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:69) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at > >> > org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:127) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at > >> > org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:124) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [rt.jar:1.8.0] > >> > >> at > >> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > >> [rt.jar:1.8.0] > >> > >> at > >> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > >> [rt.jar:1.8.0] > >> > >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > >> > >> at org.jboss.threads.JBossThread.run(JBossThread.java:122) > >> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > >> > >> Caused by: org.jboss.modules.ModuleLoadException: Error loading module > >> from > >> > /Users/arungupta/tools/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/module.xml > >> > >> at > >> > org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:154) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at > >> > org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:131) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:154) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:148) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at java.security.AccessController.doPrivileged(Native Method) > >> [rt.jar:1.8.0] > >> > >> at > >> > org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:148) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:456) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:359) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:306) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at > >> > org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178) > >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] > >> > >> ... 8 more > >> > >> Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to > >> resolve artifact > >> 'org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT' > >> (position: END_TAG seen > >> ...org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT"/>... > >> @35:91) > >> > >> at > >> > org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:752) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at > >> > org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:647) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at > >> > org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:445) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at > >> > org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:264) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> at > >> > org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:152) > >> [jboss-modules.jar:1.3.4.Final] > >> > >> ... 18 more > >> > >> > >> 14:41:32,061 FATAL [org.jboss.as.server] (Controller Boot Thread) > >> WFLYSRV0056: Server boot has failed in an unrecoverable manner; > >> exiting. See previous messages for details. > >> > >> 14:41:32,073 INFO [org.jboss.as] (MSC service thread 1-6) > >> WFLYSRV0050: WildFly 1.0.0.Alpha5 "Kenny" stopped in 7ms > >> > >> > >> Do I need to install > >> feature-pack/target/wildfly-9.0.0.Alpha1-SNAPSHOT.zip ? How ? > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140821/5d88568c/attachment-0001.html From arun.gupta at gmail.com Wed Aug 20 18:52:25 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 20 Aug 2014 15:52:25 -0700 Subject: [wildfly-dev] Install WildFly 9 failing to start In-Reply-To: References: Message-ID: Thanks! Where can I find details about other WildFly 9 features mentioned on the blog ? Links to discussion on wildfly-dev ? Arun On Wed, Aug 20, 2014 at 3:51 PM, Toma? Cerar wrote: > Ah nevermind, fix that fixes your problem is not part of jboss-modules 1.3.4 > yet. > > anyhow, we have on our radar. > > > On Thu, Aug 21, 2014 at 12:45 AM, Arun Gupta wrote: >> >> "install" builds the correct distribution. Zip bundle built using >> "package" was giving this error. >> >> On Wed, Aug 20, 2014 at 3:31 PM, Toma? Cerar >> wrote: >> > use dist/target/ not build/target for time being. >> Updated the blog as well >> >> > >> > how do your maven settings.xml look like? >> No settings.xml >> >> > >> > and where do you have it? in user.home/.m2/settings.xml? >> Nothing there >> >> > in M2_HOME/conf/settings.xml? >> No conf in M2_HOME >> >> > or even somewhere else? >> Nope >> >> Arun >> >> > >> > -- >> > tomaz >> > >> > >> > >> > On Wed, Aug 20, 2014 at 11:48 PM, Arun Gupta >> > wrote: >> >> >> >> Built the trunk using "mvn package" >> >> Unzipped "target/wildfly-9.0.0.Alpha1-SNAPSHOT" >> >> Started WildFly as "bin/standalone.sh" >> >> Got the following error: >> >> >> >> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option >> >> MaxPermSize=256m; support was removed in 8.0 >> >> >> >> 14:41:31,218 INFO [org.jboss.modules] (main) JBoss Modules version >> >> 1.3.4.Final >> >> >> >> 14:41:31,681 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final >> >> >> >> 14:41:31,748 INFO [org.jboss.as] (MSC service thread 1-5) >> >> WFLYSRV0049: WildFly 1.0.0.Alpha5 "Kenny" starting >> >> >> >> 14:41:32,057 ERROR [org.jboss.as.server] (Controller Boot Thread) >> >> WFLYSRV0055: Caught exception during boot: >> >> org.jboss.as.controller.persistence.ConfigurationPersistenceException: >> >> WFLYCTL0085: Failed to parse configuration >> >> >> >> at >> >> >> >> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at org.jboss.as.server.ServerService.boot(ServerService.java:343) >> >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at >> >> >> >> org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:260) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] >> >> >> >> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to >> >> load module org.jboss.as.clustering.infinispan >> >> >> >> at >> >> >> >> org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:155) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at >> >> >> >> org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:435) >> >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at >> >> >> >> org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) >> >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at >> >> >> >> org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) >> >> [wildfly-server-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at >> >> >> >> org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) >> >> [staxmapper-1.1.0.Final.jar:1.1.0.Final] >> >> >> >> at >> >> org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) >> >> [staxmapper-1.1.0.Final.jar:1.1.0.Final] >> >> >> >> at >> >> >> >> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> ... 3 more >> >> >> >> Caused by: java.util.concurrent.ExecutionException: >> >> javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load >> >> module >> >> >> >> at java.util.concurrent.FutureTask.report(FutureTask.java:122) >> >> [rt.jar:1.8.0] >> >> >> >> at java.util.concurrent.FutureTask.get(FutureTask.java:192) >> >> [rt.jar:1.8.0] >> >> >> >> at >> >> >> >> org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:147) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> ... 9 more >> >> >> >> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to >> >> load module >> >> >> >> at >> >> >> >> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:196) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at >> >> >> >> org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:69) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at >> >> >> >> org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:127) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at >> >> >> >> org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:124) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> >> [rt.jar:1.8.0] >> >> >> >> at >> >> >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> >> [rt.jar:1.8.0] >> >> >> >> at >> >> >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> [rt.jar:1.8.0] >> >> >> >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] >> >> >> >> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >> >> [jboss-threads-2.1.1.Final.jar:2.1.1.Final] >> >> >> >> Caused by: org.jboss.modules.ModuleLoadException: Error loading module >> >> from >> >> >> >> /Users/arungupta/tools/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/module.xml >> >> >> >> at >> >> >> >> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:154) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> >> >> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:131) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:154) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:148) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at java.security.AccessController.doPrivileged(Native Method) >> >> [rt.jar:1.8.0] >> >> >> >> at >> >> >> >> org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:148) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:456) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:359) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:306) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> >> >> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178) >> >> [wildfly-controller-1.0.0.Alpha5.jar:1.0.0.Alpha5] >> >> >> >> ... 8 more >> >> >> >> Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to >> >> resolve artifact >> >> 'org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT' >> >> (position: END_TAG seen >> >> >> >> ...org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT"/>... >> >> @35:91) >> >> >> >> at >> >> >> >> org.jboss.modules.ModuleXmlParser.parseArtifact(ModuleXmlParser.java:752) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> >> >> org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:647) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> >> >> org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:445) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> >> >> org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:264) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> at >> >> >> >> org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:152) >> >> [jboss-modules.jar:1.3.4.Final] >> >> >> >> ... 18 more >> >> >> >> >> >> 14:41:32,061 FATAL [org.jboss.as.server] (Controller Boot Thread) >> >> WFLYSRV0056: Server boot has failed in an unrecoverable manner; >> >> exiting. See previous messages for details. >> >> >> >> 14:41:32,073 INFO [org.jboss.as] (MSC service thread 1-6) >> >> WFLYSRV0050: WildFly 1.0.0.Alpha5 "Kenny" stopped in 7ms >> >> >> >> >> >> Do I need to install >> >> feature-pack/target/wildfly-9.0.0.Alpha1-SNAPSHOT.zip ? How ? >> >> >> >> 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 > > -- http://blog.arungupta.me http://twitter.com/arungupta From chaowan at redhat.com Thu Aug 21 02:51:41 2014 From: chaowan at redhat.com (Chao Wang) Date: Thu, 21 Aug 2014 14:51:41 +0800 Subject: [wildfly-dev] Component versions difference between Wildfly and Wildfly-Core Message-ID: <53F596FD.1060908@redhat.com> Hi, I noticed that component versions are sometimes different (newer or older) between Wildfly and Wildfly-Core pom.xml, for instance, version.org.apache.httpcomponents.httpclient is 4.2.6 in Wildfly and 4.2.1 in Wildfly-Core /< 4.2.6// //< 4.2.5// //< 0.6// //---// //> 4.2.1// //54,62d10/ version.org.jboss.modules.jboss-modules is 1.3.3.Final in Wildfly and 1.3.4.Final in Wildfly-Core: /< 1.3.3.Final// //---// //> 1.3.4.Final// //113,114d31/ As the core is split from previous whole Wildfly, in this case, do they both need to be coherent in a shared component upgrade? Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140821/3faaa568/attachment.html From darran.lofthouse at jboss.com Thu Aug 21 04:14:17 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 21 Aug 2014 09:14:17 +0100 Subject: [wildfly-dev] arquillian config to test new server element (Question) In-Reply-To: <53F4E99E.6080200@redhat.com> References: <1628358401.41843610.1408542472838.JavaMail.zimbra@redhat.com> <53F4D5B5.1040501@jboss.com> <668964488.42112001.1408558210137.JavaMail.zimbra@redhat.com> <53F4E99E.6080200@redhat.com> Message-ID: <53F5AA59.3070009@jboss.com> On 20/08/14 19:31, Brian Stansberry wrote: > The xsd should be version 2_0 then, not 1_3. Actually I think that is a must be at least 2_0 ;-) Using version 2 would cause a complication if WildFly 8 also needed an updated in this area but until WildFly 9 Final is released we can cope with that. > > The 1_x series should be reserved for EAP 6. Otherwise if EAP needs a > schema update but can't pull in everything in the current WildFly > schema, we're stuck. > > Management API versions and schemas should increment the major version > every time WildFly does. > > On 8/20/14, 1:10 PM, Rebecca Searls wrote: >> No only wfly 9 onward. >> >> ----- Original Message ----- >>> From: "Darran Lofthouse" >>> To: wildfly-dev at lists.jboss.org >>> Sent: Wednesday, August 20, 2014 1:07:01 PM >>> Subject: Re: [wildfly-dev] arquillian config to test new server element (Question) >>> >>> Sorry not answering your question but just to double check, is this >>> schema going into EAP 6? >>> >>> On 20/08/14 14:47, Rebecca Searls wrote: >>>> >>>> In Wfly 9 the JBossWS team has added a new server element in >>>> jboss-as-webservices_1_3.xsd >>>> and added the corresponding code in wfly/webservices. I have added a >>>> corresponding >>>> test in org.jboss.as.test.manualmode.ws.WSAttributesChangesTestCase. >>>> Does arquillian need to be changed in some way to access this new feature? >>>> My new code in WSAttributesChangesTestCase always fails because it can not >>>> find >>>> the new server element. I've tried running the test as follows. Both >>>> fails the >>>> same way. >>>> >>>> integration-tests.sh install >>>> -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode >>>> -Dts.noSmoke >>>> >>>> integration-tests.sh install >>>> -Dtest=org/jboss/as/test/manualmode/ws/*TestCase* -Dts.manualmode >>>> -Dts.noSmoke >>>> -Djboss.dist=$WILDFLY_HOME/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT >>>> >>>> >>>> _______________________________________________ >>>> 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 Thu Aug 21 05:24:17 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 21 Aug 2014 11:24:17 +0200 Subject: [wildfly-dev] Component versions difference between Wildfly and Wildfly-Core In-Reply-To: <53F596FD.1060908@redhat.com> References: <53F596FD.1060908@redhat.com> Message-ID: Hi, yes they should be kept in sync. If you are up for it, can you send PR to sync it? -- tomaz On Thu, Aug 21, 2014 at 8:51 AM, Chao Wang wrote: > Hi, I noticed that component versions are sometimes different (newer or > older) between Wildfly and Wildfly-Core pom.xml, for instance, > > version.org.apache.httpcomponents.httpclient is 4.2.6 in Wildfly and 4.2.1 > in Wildfly-Core > > *< > 4.2.6* > *< > 4.2.5* > *< > 0.6* > *---* > *> > 4.2.1* > *54,62d10* > > version.org.jboss.modules.jboss-modules is 1.3.3.Final in Wildfly and > 1.3.4.Final in Wildfly-Core: > > *< > 1.3.3.Final* > *---* > *> > 1.3.4.Final* > *113,114d31* > > As the core is split from previous whole Wildfly, in this case, do they > both need to be coherent in a shared component upgrade? > > Chao > > _______________________________________________ > 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/20140821/6757541c/attachment.html From chaowan at redhat.com Thu Aug 21 05:35:11 2014 From: chaowan at redhat.com (Chao Wang) Date: Thu, 21 Aug 2014 17:35:11 +0800 Subject: [wildfly-dev] Component versions difference between Wildfly and Wildfly-Core In-Reply-To: References: <53F596FD.1060908@redhat.com> Message-ID: <53F5BD4F.2020407@redhat.com> On 08/21/2014 05:24 PM, Toma? Cerar wrote: > Hi, > > yes they should be kept in sync. > > If you are up for it, can you send PR to sync it? sure, will do that. cheers > > -- > tomaz > > > On Thu, Aug 21, 2014 at 8:51 AM, Chao Wang > wrote: > > Hi, I noticed that component versions are sometimes different > (newer or older) between Wildfly and Wildfly-Core pom.xml, for > instance, > > version.org.apache.httpcomponents.httpclient is 4.2.6 in Wildfly > and 4.2.1 in Wildfly-Core > > /< > 4.2.6// > //< > 4.2.5// > //< > 0.6// > //---// > //> > 4.2.1// > //54,62d10/ > > version.org.jboss.modules.jboss-modules is 1.3.3.Final in Wildfly > and 1.3.4.Final in Wildfly-Core: > > /< > 1.3.3.Final// > //---// > //> > 1.3.4.Final// > //113,114d31/ > > As the core is split from previous whole Wildfly, in this case, do > they both need to be coherent in a shared component upgrade? > > Chao > > _______________________________________________ > 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/20140821/c4bdf8ed/attachment-0001.html From darran.lofthouse at jboss.com Thu Aug 21 06:14:18 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 21 Aug 2014 11:14:18 +0100 Subject: [wildfly-dev] Default boolean parameters to true Message-ID: <53F5C67A.1020403@jboss.com> Not talking about changing any other defaults but I have been thinking would it make sense where boolean parameters are being passed in an operation that we assume they are true if no value is specified. As an example I regularly execute the following two commands: - :read-resource(recursive=true) :whoami(verbose=true) In both cases the value feels redundant and it would be more natural to just use: - :read-resource(recursive) :whoami(verbose) Regards, Darran Lofthouse. From tomaz.cerar at gmail.com Thu Aug 21 07:00:09 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 21 Aug 2014 13:00:09 +0200 Subject: [wildfly-dev] Default boolean parameters to true In-Reply-To: <53F5C67A.1020403@jboss.com> References: <53F5C67A.1020403@jboss.com> Message-ID: What do you have in mind, CLI enhancement to handle this. or global handling of operation handlers on the server? On Thu, Aug 21, 2014 at 12:14 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > Not talking about changing any other defaults but I have been thinking > would it make sense where boolean parameters are being passed in an > operation that we assume they are true if no value is specified. > > As an example I regularly execute the following two commands: - > > :read-resource(recursive=true) > :whoami(verbose=true) > > In both cases the value feels redundant and it would be more natural to > just use: - > > :read-resource(recursive) > :whoami(verbose) > > 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/20140821/b33328dd/attachment.html From darran.lofthouse at jboss.com Thu Aug 21 08:26:50 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 21 Aug 2014 13:26:50 +0100 Subject: [wildfly-dev] Default boolean parameters to true In-Reply-To: References: <53F5C67A.1020403@jboss.com> Message-ID: <53F5E58A.8010908@jboss.com> I would expect it would need to be a CLI change. On 21/08/14 12:00, Toma? Cerar wrote: > What do you have in mind, CLI enhancement to handle this. > or global handling of operation handlers on the server? > > > On Thu, Aug 21, 2014 at 12:14 PM, Darran Lofthouse > > wrote: > > Not talking about changing any other defaults but I have been thinking > would it make sense where boolean parameters are being passed in an > operation that we assume they are true if no value is specified. > > As an example I regularly execute the following two commands: - > > :read-resource(recursive=true) > :whoami(verbose=true) > > In both cases the value feels redundant and it would be more natural to > just use: - > > :read-resource(recursive) > :whoami(verbose) > > Regards, > Darran Lofthouse. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From brian.stansberry at redhat.com Thu Aug 21 09:45:24 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 21 Aug 2014 08:45:24 -0500 Subject: [wildfly-dev] Default boolean parameters to true In-Reply-To: <53F5E58A.8010908@jboss.com> References: <53F5C67A.1020403@jboss.com> <53F5E58A.8010908@jboss.com> Message-ID: <53F5F7F4.5030208@redhat.com> Sounds reasonable to me. On 8/21/14, 7:26 AM, Darran Lofthouse wrote: > I would expect it would need to be a CLI change. > > On 21/08/14 12:00, Toma? Cerar wrote: >> What do you have in mind, CLI enhancement to handle this. >> or global handling of operation handlers on the server? >> >> >> On Thu, Aug 21, 2014 at 12:14 PM, Darran Lofthouse >> > wrote: >> >> Not talking about changing any other defaults but I have been thinking >> would it make sense where boolean parameters are being passed in an >> operation that we assume they are true if no value is specified. >> >> As an example I regularly execute the following two commands: - >> >> :read-resource(recursive=true) >> :whoami(verbose=true) >> >> In both cases the value feels redundant and it would be more natural to >> just use: - >> >> :read-resource(recursive) >> :whoami(verbose) >> >> Regards, >> Darran Lofthouse. >> >> _______________________________________________ >> 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 alexey.loubyansky at redhat.com Thu Aug 21 11:59:55 2014 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Thu, 21 Aug 2014 17:59:55 +0200 Subject: [wildfly-dev] Default boolean parameters to true In-Reply-To: <53F5E58A.8010908@jboss.com> References: <53F5C67A.1020403@jboss.com> <53F5E58A.8010908@jboss.com> Message-ID: <53F6177B.60002@redhat.com> I like that. Alexey On 08/21/2014 02:26 PM, Darran Lofthouse wrote: > I would expect it would need to be a CLI change. > > On 21/08/14 12:00, Toma? Cerar wrote: >> What do you have in mind, CLI enhancement to handle this. >> or global handling of operation handlers on the server? >> >> >> On Thu, Aug 21, 2014 at 12:14 PM, Darran Lofthouse >> > wrote: >> >> Not talking about changing any other defaults but I have been thinking >> would it make sense where boolean parameters are being passed in an >> operation that we assume they are true if no value is specified. >> >> As an example I regularly execute the following two commands: - >> >> :read-resource(recursive=true) >> :whoami(verbose=true) >> >> In both cases the value feels redundant and it would be more natural to >> just use: - >> >> :read-resource(recursive) >> :whoami(verbose) >> >> Regards, >> Darran Lofthouse. >> >> _______________________________________________ >> 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 Thu Aug 21 16:57:23 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 21 Aug 2014 22:57:23 +0200 Subject: [wildfly-dev] Compilation error for wildfly-core 1.0.0.Alpha5 In-Reply-To: References: <000a01cfbc78$476f2f00$d64d8d00$@HS-Karlsruhe.de> Message-ID: new version of wildfly-build-tools is released and version updated in wildfly-core. -- tomaz On Wed, Aug 20, 2014 at 6:11 PM, Toma? Cerar wrote: > PR that fixes build plugin sent > https://github.com/wildfly/wildfly-build-tools/pull/3 > > > On Wed, Aug 20, 2014 at 4:30 PM, Toma? Cerar > wrote: > >> Hi, >> >> It looks like new build merged yesterday doesn't work properly on windows. >> >> I am looking into fixing it. >> >> -- >> tomaz >> >> >> On Wed, Aug 20, 2014 at 3:11 PM, J?rgen Zimmermann < >> Juergen.Zimmermann at hs-karlsruhe.de> wrote: >> >>> From https://github.com/wildfly/wildfly-core/tree/1.0.0.Alpha5 I cloned >>> wildfly-core and tried to compile, but failed (see below). On a windows 8.1 >>> box with JDK 1.8.0_11 I used the command ?mvn clean install?. I also tried >>> to add ?-Dskip-enforce?. Any hint is appreciated. >>> >>> >>> >>> The maven output: >>> >>> ? >>> >>> [INFO] WildFly: Core Feature Pack ......................... SUCCESS [ >>> 3.355 s] >>> >>> [INFO] WildFly: Build Core ................................ FAILURE [ >>> 2.109 s] >>> >>> [INFO] WildFly Core: Distribution ......................... SKIPPED >>> >>> [INFO] WildFly: Core Model Test Controller Optional ....... SKIPPED >>> >>> [INFO] WildFly: Core Model Tests .......................... SKIPPED >>> >>> [INFO] WildFly: IO Subsystem tests ........................ SKIPPED >>> >>> [INFO] WildFly: Remoting Subsystem Test ................... SKIPPED >>> >>> [INFO] WildFly: Subsystem Test Framework Tests ............ SKIPPED >>> >>> [INFO] WildFly Core Test Suite: Shared .................... SKIPPED >>> >>> [INFO] WildFly: Test Runner ............................... SKIPPED >>> >>> [INFO] WildFly core Test Suite: Aggregator ................ SKIPPED >>> >>> [INFO] WildFly Core Test Suite: Standalone Integration Tests SKIPPED >>> >>> [INFO] >>> ------------------------------------------------------------------------ >>> >>> [INFO] BUILD FAILURE >>> >>> [INFO] >>> ------------------------------------------------------------------------ >>> >>> [INFO] Total time: 01:44 min >>> >>> [INFO] Finished at: 2014-08-20T14:59:38+02:00 >>> >>> [INFO] Final Memory: 113M/752M >>> >>> [INFO] >>> ------------------------------------------------------------------------ >>> >>> [ERROR] Failed to execute goal >>> org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:build >>> (server-provisioning) on project wildfly-core-build: Execution >>> server-provisioning of goal >>> org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha1:build >>> failed: java.lang.RuntimeException: java.lang.IllegalStateException: Could >>> not resolve '[subsystem=logging.xml, supplement=null] -> [Help 1] >>> >>> [ERROR] >>> >>> [ERROR] To see the full stack trace of the errors, re-run Maven with the >>> -e switch. >>> >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>> >>> [ERROR] >>> >>> [ERROR] For more information about the errors and possible solutions, >>> please read the following articles: >>> >>> [ERROR] [Help 1] >>> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException >>> >>> [ERROR] >>> >>> [ERROR] After correcting the problems, you can resume the build with the >>> command >>> >>> [ERROR] mvn -rf :wildfly-core-build >>> >>> _______________________________________________ >>> 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/20140821/43e3fa6e/attachment.html From rory.odonnell at oracle.com Fri Aug 22 04:51:55 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Fri, 22 Aug 2014 09:51:55 +0100 Subject: [wildfly-dev] Early Access build for JDK 9 b27 is available on java.net Message-ID: <53F704AB.2070806@oracle.com> Hi Guys, Early Access build for JDK 9 b27 is available on java.net, summary of changes here I'd also like to use this opportunity to point you to ongoing work in OpenJDK on Project Jigsaw. - JDK 9's source code is now modular: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-August/001220.html - Mark Reinhold's post providing some context is available on his blog: http://mreinhold.org/blog/jigsaw-phase-two - The first two Project Jigsaw JEPs have been posted at http://openjdk.java.net/jeps/200 & http://openjdk.java.net/jeps/201 . You can also track the progress on the JEPs in the JDK Bug System now - the corresponding JBS issue for JEP 201 is https://bugs.openjdk.java.net/browse/JDK-8051619 , for example. Comments, questions, and suggestions are welcome on the jigsaw-dev mailing list. (If you haven?t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.) 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/20140822/98d4e62d/attachment-0001.html From hbraun at redhat.com Mon Aug 25 05:35:45 2014 From: hbraun at redhat.com (Heiko Braun) Date: Mon, 25 Aug 2014 11:35:45 +0200 Subject: [wildfly-dev] Cassandra Subsystem Message-ID: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> FYI I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's own. The integration is done as a subsystem, which can be used to run a a single C* node on a standalone box, but more importantly it allows for launching and managing a complete C* cluster as part of Wildfly managed domain. I've provided example configuration files for both options which can be used to play around with it and get going. The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra isn't designed to be used an embedded library. In particular the CassandraDaemon and some of the core services make heavy use 'System.exit()' calls. In order to embed Cassandra as a managed service, we had to remove some of the code that would otherwise break the service contracts in Wildfly. But I am confident we can find a way to get these changes back into the upstream project. But I haven't discussed all the details with the Apache folks yet. Overall it's pretty much work in progress, but I think it's good enough to get your hands dirty. You can find the codebase in my github repository: https://github.com/heiko-braun/wildfly-cassandra Thoughts and comments are welcome. /Heiko [1] http://cassandra.apache.org/ [2] https://github.com/rhq-project/rhq-metrics From smarlow at redhat.com Mon Aug 25 11:27:07 2014 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 25 Aug 2014 11:27:07 -0400 Subject: [wildfly-dev] blocking JPA issue with resources getting de-listed from transaction too early on WildFly 8.x + master... Message-ID: <53FB55CB.6090704@redhat.com> To address a leak with some resource adapters, WildFly is de-listing resources during the (IronJacamar) Synchronization.beforeCompletion time, however this can happen before all of the persistence providers have saved their changes to the database. This is likely to be the case for applications that have more than one persistence unit used per transaction. The impact is that only the first referenced persistence provider, is part of the transaction. The other database changes will run as local database changes. This was reported recently via [1] + [2] + [3]. Discussion about how to best address is ongoing (would be nice to have both the resource leak fix and a way to run the IronJacamar Synchronization.beforeCompletion last). This is a blocking issue for any jiras that we create to handle this. This problem is not in earlier application server versions (only in WildFly 8.0 and higher). Workaround: Using a single persistence unit per transaction should workaround this but a code fix will be better. Scott [1] WF user forum description of problem https://community.jboss.org/message/901613 [2] Narayana dev mailing list post about sync ordering https://community.jboss.org/message/901880 [3] original jira that reported this issue that I rejected https://issues.jboss.org/browse/WFLY-3619 From stuart.w.douglas at gmail.com Tue Aug 26 00:19:28 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 26 Aug 2014 14:19:28 +1000 Subject: [wildfly-dev] Graceful shutdown Message-ID: <53FC0AD0.9000706@gmail.com> Hi all, The first graceful shutdown code has now gone into Wildfly upstream, and it should be possible to now start implementing this for all endpoints (at the moment it is only implemented for Undertow and remote EJB). Basically a server can be suspended by executing the :suspend operation in the CLI, and resumed using the :resume operation (there are corresponding options in domain mode as well that can be executed at domain, server group and server level). Servers can also be suspended by doing a graceful shutdown, which basically involves passing a timeout parameter to the :shutdown command (so :shutdown(timeout=60) will suspend the server, wait up to 60 seconds for all current requests to finish, then shut down). From a code point of view there are two main constructs, org.jboss.as.server.suspend.SuspendController, which is notified of suspend events, and org.wildfly.extension.requestcontroller.RequestController, which deals with the common case of tracking active requests (and also allows a global request limit to be put in place as a form of overload protection). Subsystems that wish to use the SuspendController directly do this by registering ServerActivity callbacks, these callbacks notify the subsystem when the server is being suspended and resumed, and allow the subsystem to notify the server when the subsystem has suspended. This happens in two stages: - preSuspend() this is called first, and allows things like mod_cluster to notify the load balancer that the server is being suspended. During this phase the server processes requests normally. - suspend() this is called once the preSuspend() phase has completed, once suspend has started the subsystem should stop accepting requests, and notify the server once it considers itself fully suspended. Subsystems that wish to use RequestController do this by getting access to a ControlPoint, which is identified by (top level) deployment name + entry point name. When an external request starts the code calls beginRequest() and checks the return value to see if the request is allowed to proceed. If it is allowed then the code must call requestComplete() when it is finished. Note that this can only be used for external requests, or it can break already running code (e.g. @PreDestroy calls that are running when the server is suspended). Because the request controller tracks the deployment and entry point we may eventually use this information to also provide: - deployment level suspend (so we can do 'graceful undeploy') - entry point level suspend (e.g. suspend all web requests) - statistics on active requests by deployment/entry point Note that RequstController is a subsystem, and the request tracking does add a small amount of overhead. If the subsystem is removed then this overhead will disappear, however graceful shutdown will then not track active requests. All questions/comments are welcome, now that the core is in place I am going to start creating JIRA's for all the subsystem level integration work. Stuart From rory.odonnell at oracle.com Tue Aug 26 03:56:24 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Tue, 26 Aug 2014 08:56:24 +0100 Subject: [wildfly-dev] Early Access build for JDK 8u40 build 02 is available on java.net Message-ID: <53FC3DA8.8030907@oracle.com> Hi Guys, Early Access build for JDK 8u40 build 02 is available on java.net. Summary of changes in JDK 8u40 build 02 are listed here. Early Access Build Test Results 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/20140826/845bc0d6/attachment.html From pmuir at redhat.com Tue Aug 26 06:05:02 2014 From: pmuir at redhat.com (Pete Muir) Date: Tue, 26 Aug 2014 11:05:02 +0100 Subject: [wildfly-dev] Rename wildfly/archetypes -> wildfly/wildfly-archetypes and add archetypes for creating applications Message-ID: As per subject, we would like to rename the repo to follow the normal naming process. We would also like to add and release a couple of archetypes for creating web-app projects for WildFly. Any objections? From andrei.tchijov at vgw.co Tue Aug 26 06:51:35 2014 From: andrei.tchijov at vgw.co (Andrei Tchijov) Date: Tue, 26 Aug 2014 13:51:35 +0300 Subject: [wildfly-dev] Handling non-HTTP based request Message-ID: Hi, Can some one advice on implementation of non HTTP based request handler inside wildfly? I am trying to avoid to deploy separate server to handle Flash Socket Policy File requests.? Ideally, I would like to have some kind of "socket connection filter" - which will test if the request is for Socket Policy File and serve it. if request is NOT for the policy file, it would pass processing to "default" handler Cheers, Andrei Tchijov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140826/29ae9ec0/attachment.html From ssilvert at redhat.com Tue Aug 26 08:36:40 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 26 Aug 2014 08:36:40 -0400 Subject: [wildfly-dev] Graceful shutdown In-Reply-To: <53FC0AD0.9000706@gmail.com> References: <53FC0AD0.9000706@gmail.com> Message-ID: <53FC7F58.9040302@redhat.com> Nice. This is something we've been trying to do for more than a decade. I was in a JBoss training about a year before I joined the company. I remember Marc Fleury claiming that graceful shutdown was "almost working". It looks like that this time you'll pull it off. On 8/26/2014 12:19 AM, Stuart Douglas wrote: > Hi all, > > The first graceful shutdown code has now gone into Wildfly upstream, and > it should be possible to now start implementing this for all endpoints > (at the moment it is only implemented for Undertow and remote EJB). > > Basically a server can be suspended by executing the :suspend operation > in the CLI, and resumed using the :resume operation (there are > corresponding options in domain mode as well that can be executed at > domain, server group and server level). Servers can also be suspended by > doing a graceful shutdown, which basically involves passing a timeout > parameter to the :shutdown command (so :shutdown(timeout=60) will > suspend the server, wait up to 60 seconds for all current requests to > finish, then shut down). > > From a code point of view there are two main constructs, > org.jboss.as.server.suspend.SuspendController, which is notified of > suspend events, and > org.wildfly.extension.requestcontroller.RequestController, which deals > with the common case of tracking active requests (and also allows a > global request limit to be put in place as a form of overload protection). > > Subsystems that wish to use the SuspendController directly do this by > registering ServerActivity callbacks, these callbacks notify the > subsystem when the server is being suspended and resumed, and allow the > subsystem to notify the server when the subsystem has suspended. This > happens in two stages: > > - preSuspend() this is called first, and allows things like mod_cluster > to notify the load balancer that the server is being suspended. During > this phase the server processes requests normally. > > - suspend() this is called once the preSuspend() phase has completed, > once suspend has started the subsystem should stop accepting requests, > and notify the server once it considers itself fully suspended. > > > Subsystems that wish to use RequestController do this by getting access > to a ControlPoint, which is identified by (top level) deployment name + > entry point name. When an external request starts the code calls > beginRequest() and checks the return value to see if the request is > allowed to proceed. If it is allowed then the code must call > requestComplete() when it is finished. > > Note that this can only be used for external requests, or it can break > already running code (e.g. @PreDestroy calls that are running when the > server is suspended). > > Because the request controller tracks the deployment and entry point we > may eventually use this information to also provide: > > - deployment level suspend (so we can do 'graceful undeploy') > - entry point level suspend (e.g. suspend all web requests) > - statistics on active requests by deployment/entry point > > Note that RequstController is a subsystem, and the request tracking does > add a small amount of overhead. If the subsystem is removed then this > overhead will disappear, however graceful shutdown will then not track > active requests. > > All questions/comments are welcome, now that the core is in place I am > going to start creating JIRA's for all the subsystem level integration work. > > Stuart > _______________________________________________ > 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 Aug 26 09:05:57 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 26 Aug 2014 06:05:57 -0700 Subject: [wildfly-dev] Rename wildfly/archetypes -> wildfly/wildfly-archetypes and add archetypes for creating applications Message-ID: <-8355667449386973450@unknownmsgid> Go for it. Sent from my PhoneFrom: Pete Muir Sent: ?26/?08/?2014 12:05 To: WildFly Dev Cc: Rafael Benevides Subject: [wildfly-dev] Rename wildfly/archetypes -> wildfly/wildfly-archetypes and add archetypes for creating applications As per subject, we would like to rename the repo to follow the normal naming process. We would also like to add and release a couple of archetypes for creating web-app projects for WildFly. Any objections? _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Tue Aug 26 09:10:39 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 26 Aug 2014 08:10:39 -0500 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> Message-ID: <53FC874F.9000804@redhat.com> On 8/25/14, 4:35 AM, Heiko Braun wrote: > > FYI > > I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's own. > > The integration is done as a subsystem, which can be used to run a a single C* node on a standalone box, but more importantly it allows for launching and managing a complete C* cluster as part of Wildfly managed domain. I've provided example configuration files for both options which can be used to play around with it and get going. > > The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra isn't designed to be used an embedded library. In particular the CassandraDaemon and some of the core services make heavy use 'System.exit()' calls. In order to embed Cassandra as a managed service, we had to remove some of the code that would otherwise break the service contracts in Wildfly. But I am confident we can find a way to get these changes back into the upstream project. But I haven't discussed all the details with the Apache folks yet. > > Overall it's pretty much work in progress, but I think it's good enough to get your hands dirty. You can find the codebase in my github repository: > > https://github.com/heiko-braun/wildfly-cassandra > > Thoughts and comments are welcome. One possible option might be to run it as a subprocess. -- - DML From hbraun at redhat.com Tue Aug 26 09:23:20 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 26 Aug 2014 15:23:20 +0200 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <53FC874F.9000804@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC874F.9000804@redhat.com> Message-ID: <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> Not sure I can follow. Do you refer to the System.exit() calls? On 26 Aug 2014, at 15:10, David M. Lloyd wrote: > One possible option might be to run it as a subprocess. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140826/7f57bb0f/attachment.html From brian.stansberry at redhat.com Tue Aug 26 09:32:51 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 26 Aug 2014 08:32:51 -0500 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> Message-ID: <53FC8C83.90705@redhat.com> One thing we'll need to sort through is the socket configuration. It looks like some addresses and ports are being directly configured in the subsystem. These should be done via references to socket bindings (for server sockets) and outbound socket bindings (for client sockets). This will complicate things a bit in terms of wiring up the services, but it shouldn't be a big deal; we do it lots of places. On 8/25/14, 4:35 AM, Heiko Braun wrote: > > FYI > > I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's own. > > The integration is done as a subsystem, which can be used to run a a single C* node on a standalone box, but more importantly it allows for launching and managing a complete C* cluster as part of Wildfly managed domain. I've provided example configuration files for both options which can be used to play around with it and get going. > > The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra isn't designed to be used an embedded library. In particular the CassandraDaemon and some of the core services make heavy use 'System.exit()' calls. In order to embed Cassandra as a managed service, we had to remove some of the code that would otherwise break the service contracts in Wildfly. But I am confident we can find a way to get these changes back into the upstream project. But I haven't discussed all the details with the Apache folks yet. > > Overall it's pretty much work in progress, but I think it's good enough to get your hands dirty. You can find the codebase in my github repository: > > https://github.com/heiko-braun/wildfly-cassandra > > Thoughts and comments are welcome. > > /Heiko > > [1] http://cassandra.apache.org/ > [2] https://github.com/rhq-project/rhq-metrics > > > > _______________________________________________ > 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 hbraun at redhat.com Tue Aug 26 10:00:41 2014 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 26 Aug 2014 16:00:41 +0200 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <53FC8C83.90705@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC8C83.90705@redhat.com> Message-ID: <70BD7E30-A2D2-43E9-8D59-B8E29427347E@redhat.com> Yeah, agreed. I already had that on my list of todos. > Am 26.08.2014 um 15:32 schrieb Brian Stansberry : > > One thing we'll need to sort through is the socket configuration. It > looks like some addresses and ports are being directly configured in the > subsystem. These should be done via references to socket bindings (for > server sockets) and outbound socket bindings (for client sockets). > > This will complicate things a bit in terms of wiring up the services, > but it shouldn't be a big deal; we do it lots of places. > >> On 8/25/14, 4:35 AM, Heiko Braun wrote: >> >> FYI >> >> I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's own. >> >> The integration is done as a subsystem, which can be used to run a a single C* node on a standalone box, but more importantly it allows for launching and managing a complete C* cluster as part of Wildfly managed domain. I've provided example configuration files for both options which can be used to play around with it and get going. >> >> The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra isn't designed to be used an embedded library. In particular the CassandraDaemon and some of the core services make heavy use 'System.exit()' calls. In order to embed Cassandra as a managed service, we had to remove some of the code that would otherwise break the service contracts in Wildfly. But I am confident we can find a way to get these changes back into the upstream project. But I haven't discussed all the details with the Apache folks yet. >> >> Overall it's pretty much work in progress, but I think it's good enough to get your hands dirty. You can find the codebase in my github repository: >> >> https://github.com/heiko-braun/wildfly-cassandra >> >> Thoughts and comments are welcome. >> >> /Heiko >> >> [1] http://cassandra.apache.org/ >> [2] https://github.com/rhq-project/rhq-metrics >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From pmuir at redhat.com Tue Aug 26 10:20:26 2014 From: pmuir at redhat.com (Pete Muir) Date: Tue, 26 Aug 2014 15:20:26 +0100 Subject: [wildfly-dev] Rename wildfly/archetypes -> wildfly/wildfly-archetypes and add archetypes for creating applications In-Reply-To: <-8355667449386973450@unknownmsgid> References: <-8355667449386973450@unknownmsgid> Message-ID: Thanks Tomaz. I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. Pete On 26 Aug 2014, at 14:05, Toma? Cerar wrote: > Go for it. > > Sent from my PhoneFrom: Pete Muir > Sent: ?26/?08/?2014 12:05 > To: WildFly Dev > Cc: Rafael Benevides > Subject: [wildfly-dev] Rename wildfly/archetypes -> > wildfly/wildfly-archetypes and add archetypes for creating applications > As per subject, we would like to rename the repo to follow the normal > naming process. We would also like to add and release a couple of > archetypes for creating web-app projects for WildFly. > > Any objections? > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Tue Aug 26 11:36:19 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 26 Aug 2014 10:36:19 -0500 Subject: [wildfly-dev] Cassandra Subsystem In-Reply-To: <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> References: <78CCAB36-F425-4633-8336-5053914CCFFA@redhat.com> <53FC874F.9000804@redhat.com> <43D71725-DCDF-44BA-9A33-DFBE19EA8BCE@redhat.com> Message-ID: <53FCA973.5050203@redhat.com> Yeah, you could have a service that controls the cassandra daemon as a service and uses whatever its default network API is for communications. This should be safe and reliable as of JDK 7. Just a suggestion in case embedding becomes an untenable proposition. On 8/26/14, 8:23 AM, Heiko Braun wrote: > > > Not sure I can follow. Do you refer to the System.exit() calls? > > On 26 Aug 2014, at 15:10, David M. Lloyd > wrote: > >> One possible option might be to run it as a subprocess. > -- - DML From benevides at redhat.com Tue Aug 26 12:39:34 2014 From: benevides at redhat.com (Rafael Benevides) Date: Tue, 26 Aug 2014 13:39:34 -0300 Subject: [wildfly-dev] New wildfly-javaee7-webapp Archetypes In-Reply-To: References: <-8355667449386973450@unknownmsgid> Message-ID: <53FCB846.2070705@redhat.com> Hi all, I added the *wildfly-javaee7-webapp-*-archetype* to https://github.com/wildfly/wildfly-archetypes and also performed a release of them as 8.1.0.CR1 to https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3775/ This will give us a chance to test it before I can promote this staged repository. Note that these Archetypes are kept synchronized with its original quickstarts from https://github.com/wildfly/quickstart through QSTools ( http://jboss-developer.github.io/maven-qstools-plugin/ ) Once that everybody is ok, I can do a *.Final* release and ask it to be synched with Maven Central Every feedback is welcome! Thanks Em 8/26/14, 11:20, Pete Muir escreveu: > Thanks Tomaz. > > I did the rename (https://github.com/wildfly/wildfly-archetypes). I added the archetypes-push team, and put Rafael in it, so he can manage these archetypes. > > Pete > > On 26 Aug 2014, at 14:05, Toma? Cerar wrote: > >> Go for it. >> >> Sent from my PhoneFrom: Pete Muir >> Sent: ?26/?08/?2014 12:05 >> To: WildFly Dev >> Cc: Rafael Benevides >> Subject: [wildfly-dev] Rename wildfly/archetypes -> >> wildfly/wildfly-archetypes and add archetypes for creating applications >> As per subject, we would like to rename the repo to follow the normal >> naming process. We would also like to add and release a couple of >> archetypes for creating web-app projects for WildFly. >> >> Any objections? >> _______________________________________________ >> 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/20140826/ddfb62b1/attachment.html From stuart.w.douglas at gmail.com Wed Aug 27 00:09:23 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 27 Aug 2014 14:09:23 +1000 Subject: [wildfly-dev] Splitting up the build, next steps Message-ID: <53FD59F3.4090100@gmail.com> Hi all, So now the core split has been in place for a while we are going to start to look at splitting the build up further, as per the original plan. As such the next logical step is to introduce a wildfly-web repo, which corresponds to the web-build feature pack in the wildfly repo. This feature pack will basically be a servlet container (think Tomcat or Jetty), as well as containing core EE and JNDI functionality. I am hoping to start on this early next week, and don't imagine it will take too much time, so if anyone has any concerns or questions please let me know. Stuart From hbraun at redhat.com Wed Aug 27 05:10:44 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 27 Aug 2014 11:10:44 +0200 Subject: [wildfly-dev] JDBC stats, clarification needed Message-ID: <0804AC44-95A5-4AB5-BA1A-BD2FCA4A8B33@redhat.com> I am trying to make sense of the data source stats and need some help. Can someone explain these figures to me? The hit count is smaller then the access count. I would expect the other accesses to show up in the miss count, but they don't. Is it a bug or do I misinterpret these numbers? [standalone at localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "PreparedStatementCacheAccessCount" => "41", "PreparedStatementCacheAddCount" => "6", "PreparedStatementCacheCurrentSize" => "6", "PreparedStatementCacheDeleteCount" => "0", "PreparedStatementCacheHitCount" => "35", "PreparedStatementCacheMissCount" => "0", "statistics-enabled" => true } } Regards, Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140827/cca3df72/attachment-0001.html From eduardo.santanadasilva at gmail.com Wed Aug 27 06:58:32 2014 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Wed, 27 Aug 2014 07:58:32 -0300 Subject: [wildfly-dev] JDBC stats, clarification needed In-Reply-To: <0804AC44-95A5-4AB5-BA1A-BD2FCA4A8B33@redhat.com> References: <0804AC44-95A5-4AB5-BA1A-BD2FCA4A8B33@redhat.com> Message-ID: <235E1BC4-43CC-48F7-B521-F3B41DE4D37B@gmail.com> /** * JBQA-6456 Test jdbc statistics of data sources * * @author Vladimir Rastseluev */ @RunWith(Arquillian.class) @ServerSetup(DataSourceJdbcStatisticsTestCase.TestCaseSetup.class) public class DataSourceJdbcStatisticsTestCase { ... public StringBuffer assertStatisticsSet(boolean yes, ModelNode statisticNode) throws Exception { StringBuffer sb = new StringBuffer(); String[] params = { "PreparedStatementCacheAccessCount", // The number of times that the statement cache was // accessed "PreparedStatementCacheAddCount", // The number of statements added to the statement cache "PreparedStatementCacheCurrentSize", // The number of prepared and callable statements currently cached in // the statement cache "PreparedStatementCacheDeleteCount", // The number of statements discarded from the cache "PreparedStatementCacheHitCount" // The number of times that statements from the cache were used }; On Aug 27, 2014, at 6:10 AM, Heiko Braun wrote: > PreparedStatementCacheAccessCount -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140827/84bf167d/attachment.html From eduardo.santanadasilva at gmail.com Wed Aug 27 07:19:25 2014 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Wed, 27 Aug 2014 08:19:25 -0300 Subject: [wildfly-dev] JDBC stats, clarification needed In-Reply-To: <235E1BC4-43CC-48F7-B521-F3B41DE4D37B@gmail.com> References: <0804AC44-95A5-4AB5-BA1A-BD2FCA4A8B33@redhat.com> <235E1BC4-43CC-48F7-B521-F3B41DE4D37B@gmail.com> Message-ID: <2D3D00A2-4FC9-47F3-AF3C-474C69399A4E@gmail.com> You have 41 prepared statment access to the cache. This not mean that you have 41 different statements. This means that you have actually only 6 different. Those 6 were added initially to the cache and the other 35 access found them on the cache, so you have 35 hits. On Aug 27, 2014, at 7:58 AM, Eduardo Sant'Ana da Silva wrote: > > /** > * JBQA-6456 Test jdbc statistics of data sources > * > * @author Vladimir Rastseluev > */ > > @RunWith(Arquillian.class) > @ServerSetup(DataSourceJdbcStatisticsTestCase.TestCaseSetup.class) > public class DataSourceJdbcStatisticsTestCase { > > ... > > public StringBuffer assertStatisticsSet(boolean yes, ModelNode statisticNode) throws Exception { > StringBuffer sb = new StringBuffer(); > String[] params = { "PreparedStatementCacheAccessCount", // The number of times that the statement cache was > // accessed > "PreparedStatementCacheAddCount", // The number of statements added to the statement cache > "PreparedStatementCacheCurrentSize", // The number of prepared and callable statements currently cached in > // the statement cache > "PreparedStatementCacheDeleteCount", // The number of statements discarded from the cache > "PreparedStatementCacheHitCount" // The number of times that statements from the cache were used > > }; > > > On Aug 27, 2014, at 6:10 AM, Heiko Braun wrote: > >> PreparedStatementCacheAccessCount > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140827/27b03df2/attachment.html From eduardo.santanadasilva at gmail.com Wed Aug 27 07:33:51 2014 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 27 Aug 2014 08:33:51 -0300 Subject: [wildfly-dev] JDBC stats, clarification needed In-Reply-To: <0804AC44-95A5-4AB5-BA1A-BD2FCA4A8B33@redhat.com> References: <0804AC44-95A5-4AB5-BA1A-BD2FCA4A8B33@redhat.com> Message-ID: "Add count" and "miss count" are redundant attributes to me. I think that only the "miss count" should be used since in cache terms this is more commonly used and you will surely add them to cache in case of a miss. 2014-08-27 6:10 GMT-03:00 Heiko Braun : > > > I am trying to make sense of the data source stats and need some help. Can > someone explain these figures to me? The hit count is smaller then the > access count. I would expect the other accesses to show up in the miss > count, but they don't. Is it a bug or do I misinterpret these numbers? > > [standalone at localhost:9999 /] > /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "PreparedStatementCacheAccessCount" => "41", > "PreparedStatementCacheAddCount" => "6", > "PreparedStatementCacheCurrentSize" => "6", > "PreparedStatementCacheDeleteCount" => "0", > "PreparedStatementCacheHitCount" => "35", > "PreparedStatementCacheMissCount" => "0", > "statistics-enabled" => true > } > } > > > Regards, Heiko > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140827/47c73530/attachment.html From anmiller at redhat.com Wed Aug 27 08:42:04 2014 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 27 Aug 2014 08:42:04 -0400 (EDT) Subject: [wildfly-dev] JDBC stats, clarification needed In-Reply-To: <0804AC44-95A5-4AB5-BA1A-BD2FCA4A8B33@redhat.com> References: <0804AC44-95A5-4AB5-BA1A-BD2FCA4A8B33@redhat.com> Message-ID: <1956533134.12334415.1409143324102.JavaMail.zimbra@redhat.com> The AccessCount is the total number of accesses, so it is the AddCount plus the DeleteCount plus the MissCount, plus the HitCount. As you can see from the numbers, 6 + 0 + 0 + 35 = 41. Andy ----- Original Message ----- > I am trying to make sense of the data source stats and need some help. Can > someone explain these figures to me? The hit count is smaller then the > access count. I would expect the other accesses to show up in the miss > count, but they don't. Is it a bug or do I misinterpret these numbers? > [standalone at localhost:9999 /] > /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "PreparedStatementCacheAccessCount" => "41", > "PreparedStatementCacheAddCount" => "6", > "PreparedStatementCacheCurrentSize" => "6", > "PreparedStatementCacheDeleteCount" => "0", > "PreparedStatementCacheHitCount" => "35", > "PreparedStatementCacheMissCount" => "0", > "statistics-enabled" => true > } > } > Regards, Heiko > _______________________________________________ > 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/20140827/31644040/attachment-0001.html From darran.lofthouse at jboss.com Wed Aug 27 11:39:24 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 27 Aug 2014 16:39:24 +0100 Subject: [wildfly-dev] WildFly SASL and WildFly Elytron are Merging Message-ID: <53FDFBAC.90109@jboss.com> Just a FYI, originally we had the jboss-sasl project as a standalone set of SASL mechanisms - then we started working on WildFly ELytron and renamed the SASL project wildfly-sasl. We have now reached the point that dependencies are becoming more complicated between Elytron and SASL, rather than introducing one or two additional projects we have decided to take the opposite approach and merge the SASL project over to Elytron. David is in the middle of merging the two repositories, once merged it will all be available at: - https://github.com/wildfly-security/wildfly-elytron Note: This does not in any way prevent the SASL mechanisms from being used as pure SASL mechanisms. Regards, Darran Lofthouse. From arun.gupta at gmail.com Wed Aug 27 11:45:16 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 27 Aug 2014 08:45:16 -0700 Subject: [wildfly-dev] Campground Management using Java EE 7/WildFly Message-ID: Check out details at: http://blog.arungupta.me/2014/08/javaee7-real-world-campground-management-tipi-camp-wildfly/ Let me know if you know anybody who is using Java EE 7/WildFly in production and would love to feature them. Thanks Arun -- http://blog.arungupta.me http://twitter.com/arungupta From frank.langelage at osnanet.de Wed Aug 27 15:01:59 2014 From: frank.langelage at osnanet.de (Frank Langelage) Date: Wed, 27 Aug 2014 21:01:59 +0200 Subject: [wildfly-dev] ts.secman: failure since today Message-ID: <53FE2B27.9050404@osnanet.de> Could someone please have a look at this problem, caused by commit https://github.com/wildfly/wildfly/commit/31220c8aa3a3264651fda0305f95a1512e6da838 today (PR https://github.com/wildfly/wildfly/pull/6538). stuartwdouglas? kwart? [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ wildfly-ts-integ-secman --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 26 source files to /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/target/test-classes [WARNING] CAL10NAnnotationProcessor 0.8.1 initialized [WARNING] Supported source version 'RELEASE_5' from annotation processor 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than -source '1.7' [INFO] [INFO] --- maven-checkstyle-plugin:2.12.1:checkstyle (check-style) @ wildfly-ts-integ-secman --- [INFO] Starting audit... /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/CallPermissionUtilServlet.java:51:83: Unable to get class information for ServletException. /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/JSMCheckServlet.java:55:83: Unable to get class information for ServletException. /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/PrintSystemPropertyServlet.java:50:83: Unable to get class information for ServletException. Audit done. [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS [03:11 min] [INFO] WildFly Test Suite: Integration .................... SUCCESS [ 9.882 s] [INFO] WildFly Test Suite: Integration - Web .............. SUCCESS [01:50 min] [INFO] WildFly Test Suite: Integration - Smoke ............ SUCCESS [03:54 min] [INFO] WildFly Test Suite: Integration - Security Manager . FAILURE [ 12.331 s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 09:25 min [INFO] Finished at: 2014-08-27T20:24:31+02:00 [INFO] Final Memory: 100M/302M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle (check-style) on project wildfly-ts-integ-secman: An error has occurred in Checkstyle report generation. Failed during checkstyle execution: There are 3 checkstyle errors. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :wildfly-ts-integ-secman From brian.stansberry at redhat.com Wed Aug 27 16:24:56 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 27 Aug 2014 15:24:56 -0500 Subject: [wildfly-dev] ts.secman: failure since today In-Reply-To: <53FE2B27.9050404@osnanet.de> References: <53FE2B27.9050404@osnanet.de> Message-ID: <53FE3E98.4040100@redhat.com> I disabled the checkstyle plugin in that module. It's one of only two testsuite modules that have checkstyle enabled, so no great loss. Googling that failure indicates some sort of classpath problem for the plugin, so if someone can figure out the issue we can re-enable. On 8/27/14, 2:01 PM, Frank Langelage wrote: > Could someone please have a look at this problem, caused by commit > https://github.com/wildfly/wildfly/commit/31220c8aa3a3264651fda0305f95a1512e6da838 > today (PR https://github.com/wildfly/wildfly/pull/6538). > stuartwdouglas? > kwart? > > [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ > wildfly-ts-integ-secman --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 26 source files to > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/target/test-classes > [WARNING] CAL10NAnnotationProcessor 0.8.1 initialized > [WARNING] Supported source version 'RELEASE_5' from annotation processor > 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than > -source '1.7' > [INFO] > [INFO] --- maven-checkstyle-plugin:2.12.1:checkstyle (check-style) @ > wildfly-ts-integ-secman --- > [INFO] Starting audit... > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/CallPermissionUtilServlet.java:51:83: > Unable to get class information for ServletException. > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/JSMCheckServlet.java:55:83: > Unable to get class information for ServletException. > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/PrintSystemPropertyServlet.java:50:83: > Unable to get class information for ServletException. > Audit done. > > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS > [03:11 min] > [INFO] WildFly Test Suite: Integration .................... SUCCESS [ > 9.882 s] > [INFO] WildFly Test Suite: Integration - Web .............. SUCCESS > [01:50 min] > [INFO] WildFly Test Suite: Integration - Smoke ............ SUCCESS > [03:54 min] > [INFO] WildFly Test Suite: Integration - Security Manager . FAILURE [ > 12.331 s] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 09:25 min > [INFO] Finished at: 2014-08-27T20:24:31+02:00 > [INFO] Final Memory: 100M/302M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle > (check-style) on project wildfly-ts-integ-secman: An error has occurred > in Checkstyle report generation. Failed during checkstyle execution: > There are 3 checkstyle errors. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the > -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :wildfly-ts-integ-secman > > _______________________________________________ > 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 eduardo.santanadasilva at gmail.com Wed Aug 27 23:06:08 2014 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Thu, 28 Aug 2014 00:06:08 -0300 Subject: [wildfly-dev] ts.secman: failure since today In-Reply-To: <53FE3E98.4040100@redhat.com> References: <53FE2B27.9050404@osnanet.de> <53FE3E98.4040100@redhat.com> Message-ID: Seems that the RedundantThrowsCheck style feature is causing this, since it is not able to resolve the ServletException class. I don't know if this have another implications but adding the servlet dependency solve the problem and the tests ends fine. org.jboss.spec.javax.servlet jboss-servlet-api_3.1_spec ${version.org.jboss.spec.javax.servlet.jboss-servlet-api_3.1_spec} compile 2014-08-27 17:24 GMT-03:00 Brian Stansberry : > I disabled the checkstyle plugin in that module. It's one of only two > testsuite modules that have checkstyle enabled, so no great loss. > > Googling that failure indicates some sort of classpath problem for the > plugin, so if someone can figure out the issue we can re-enable. > > On 8/27/14, 2:01 PM, Frank Langelage wrote: > > Could someone please have a look at this problem, caused by commit > > > https://github.com/wildfly/wildfly/commit/31220c8aa3a3264651fda0305f95a1512e6da838 > > today (PR https://github.com/wildfly/wildfly/pull/6538). > > stuartwdouglas? > > kwart? > > > > [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ > > wildfly-ts-integ-secman --- > > [INFO] Changes detected - recompiling the module! > > [INFO] Compiling 26 source files to > > > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/target/test-classes > > [WARNING] CAL10NAnnotationProcessor 0.8.1 initialized > > [WARNING] Supported source version 'RELEASE_5' from annotation processor > > 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less than > > -source '1.7' > > [INFO] > > [INFO] --- maven-checkstyle-plugin:2.12.1:checkstyle (check-style) @ > > wildfly-ts-integ-secman --- > > [INFO] Starting audit... > > > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/CallPermissionUtilServlet.java:51:83: > > Unable to get class information for ServletException. > > > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/JSMCheckServlet.java:55:83: > > Unable to get class information for ServletException. > > > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/PrintSystemPropertyServlet.java:50:83: > > Unable to get class information for ServletException. > > Audit done. > > > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Reactor Summary: > > [INFO] > > [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS > > [03:11 min] > > [INFO] WildFly Test Suite: Integration .................... SUCCESS [ > > 9.882 s] > > [INFO] WildFly Test Suite: Integration - Web .............. SUCCESS > > [01:50 min] > > [INFO] WildFly Test Suite: Integration - Smoke ............ SUCCESS > > [03:54 min] > > [INFO] WildFly Test Suite: Integration - Security Manager . FAILURE [ > > 12.331 s] > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] BUILD FAILURE > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Total time: 09:25 min > > [INFO] Finished at: 2014-08-27T20:24:31+02:00 > > [INFO] Final Memory: 100M/302M > > [INFO] > > ------------------------------------------------------------------------ > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle > > (check-style) on project wildfly-ts-integ-secman: An error has occurred > > in Checkstyle report generation. Failed during checkstyle execution: > > There are 3 checkstyle errors. -> [Help 1] > > [ERROR] > > [ERROR] To see the full stack trace of the errors, re-run Maven with the > > -e switch. > > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > > [ERROR] > > [ERROR] For more information about the errors and possible solutions, > > please read the following articles: > > [ERROR] [Help 1] > > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > > [ERROR] > > [ERROR] After correcting the problems, you can resume the build with the > > command > > [ERROR] mvn -rf :wildfly-ts-integ-secman > > > > _______________________________________________ > > 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 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140828/b3b8d79f/attachment.html From ema at redhat.com Thu Aug 28 06:40:51 2014 From: ema at redhat.com (Jim Ma) Date: Thu, 28 Aug 2014 18:40:51 +0800 Subject: [wildfly-dev] Httpclient 4.3.2 upgrade Message-ID: <53FF0733.3000704@redhat.com> Hi, I just sent a PR[1] to upgrade apache httpclient to 4.3.2 to enable http async client transport feature [2] in the coming cxf 3.0.2 update in WFLY. If httpclient upgrade will break something I don't know in jaxrs tck, resteasy or other component, please let me know. [1] https://github.com/wildfly/wildfly/pull/6642 [2] http://cxf.apache.org/docs/asynchronous-client-http-transport.html Thanks, Jim From darran.lofthouse at jboss.com Thu Aug 28 06:42:44 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 28 Aug 2014 11:42:44 +0100 Subject: [wildfly-dev] Two More CLI Nice To Haves Message-ID: <53FF07A4.4060907@jboss.com> Just suggesting a couple more items that would be nice to have in the CLI: - 1 - Tab completion at the following point: - ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= When adding there is only a finite number of child resources that can be added. 2 - Show the default values for attributes displayed for tab completion: - [standalone at localhost:9999 / #] ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( attribute= base-dn= force= recursive= user-dn-attribute= Anyway just a couple of ideas ;-) Regards, Darran Lofthouse. From darran.lofthouse at jboss.com Thu Aug 28 06:50:53 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 28 Aug 2014 11:50:53 +0100 Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <53FF07A4.4060907@jboss.com> References: <53FF07A4.4060907@jboss.com> Message-ID: <53FF098D.4060706@jboss.com> On 28/08/14 11:42, Darran Lofthouse wrote: > Just suggesting a couple more items that would be nice to have in the CLI: - > > 1 - Tab completion at the following point: - > > ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= > > When adding there is only a finite number of child resources that can be > added. > > 2 - Show the default values for attributes displayed for tab completion: - > > [standalone at localhost:9999 / #] > ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( > attribute= base-dn= force= recursive= > user-dn-attribute= > > Anyway just a couple of ideas ;-) Or maybe at the point of adding the attribute name to the operation and pressing tab display the type, the default value and that attribute's description? > Regards, > Darran Lofthouse. > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Thu Aug 28 08:29:37 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 28 Aug 2014 07:29:37 -0500 Subject: [wildfly-dev] ts.secman: failure since today In-Reply-To: References: <53FE2B27.9050404@osnanet.de> <53FE3E98.4040100@redhat.com> Message-ID: <53FF20B1.9020902@redhat.com> Thanks for the hint re: RedundantThrowsCheck. That led me to this bit of info; basically they want to get rid of this feature and others like it that depend on classpath as they are broken.[1] I don't think we should add dependencies just to satisfy this plugin. But the check supports configurations[2] that will let us either completely suppress this problems or just turn them into logged issues and not failures. I'll send a PR for our checkstyle config to do that. [1] https://github.com/checkstyle/checkstyle/pull/177#issuecomment-48192498 [2] http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows On 8/27/14, 10:06 PM, Eduardo Sant?Ana da Silva wrote: > Seems that the RedundantThrowsCheck style feature is causing this, since > it is not able to resolve the ServletException class. > > I don't know if this have another implications but adding the servlet > dependency solve the problem and the tests ends fine. > > > > org.jboss.spec.javax.servlet > jboss-servlet-api_3.1_spec > > ${version.org.jboss.spec.javax.servlet.jboss-servlet-api_3.1_spec} > compile > > > > > > > 2014-08-27 17:24 GMT-03:00 Brian Stansberry >: > > I disabled the checkstyle plugin in that module. It's one of only two > testsuite modules that have checkstyle enabled, so no great loss. > > Googling that failure indicates some sort of classpath problem for the > plugin, so if someone can figure out the issue we can re-enable. > > On 8/27/14, 2:01 PM, Frank Langelage wrote: > > Could someone please have a look at this problem, caused by commit > > > https://github.com/wildfly/wildfly/commit/31220c8aa3a3264651fda0305f95a1512e6da838 > > today (PR https://github.com/wildfly/wildfly/pull/6538). > > stuartwdouglas? > > kwart? > > > > [INFO] --- maven-compiler-plugin:3.1:testCompile > (default-testCompile) @ > > wildfly-ts-integ-secman --- > > [INFO] Changes detected - recompiling the module! > > [INFO] Compiling 26 source files to > > > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/target/test-classes > > [WARNING] CAL10NAnnotationProcessor 0.8.1 initialized > > [WARNING] Supported source version 'RELEASE_5' from annotation > processor > > 'ch.qos.cal10n.verifier.processor.CAL10NAnnotationProcessor' less > than > > -source '1.7' > > [INFO] > > [INFO] --- maven-checkstyle-plugin:2.12.1:checkstyle (check-style) @ > > wildfly-ts-integ-secman --- > > [INFO] Starting audit... > > > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/CallPermissionUtilServlet.java:51:83: > > Unable to get class information for ServletException. > > > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/JSMCheckServlet.java:55:83: > > Unable to get class information for ServletException. > > > /home/jboss/WildFly-9.0/wildfly/testsuite/integration/secman/src/test/java/org/jboss/as/testsuite/integration/secman/servlets/PrintSystemPropertyServlet.java:50:83: > > Unable to get class information for ServletException. > > Audit done. > > > > [INFO] > > > ------------------------------------------------------------------------ > > [INFO] Reactor Summary: > > [INFO] > > [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS > > [03:11 min] > > [INFO] WildFly Test Suite: Integration .................... SUCCESS [ > > 9.882 s] > > [INFO] WildFly Test Suite: Integration - Web .............. SUCCESS > > [01:50 min] > > [INFO] WildFly Test Suite: Integration - Smoke ............ SUCCESS > > [03:54 min] > > [INFO] WildFly Test Suite: Integration - Security Manager . FAILURE [ > > 12.331 s] > > [INFO] > > > ------------------------------------------------------------------------ > > [INFO] BUILD FAILURE > > [INFO] > > > ------------------------------------------------------------------------ > > [INFO] Total time: 09:25 min > > [INFO] Finished at: 2014-08-27T20:24:31+02:00 > > [INFO] Final Memory: 100M/302M > > [INFO] > > > ------------------------------------------------------------------------ > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle > > (check-style) on project wildfly-ts-integ-secman: An error has > occurred > > in Checkstyle report generation. Failed during checkstyle execution: > > There are 3 checkstyle errors. -> [Help 1] > > [ERROR] > > [ERROR] To see the full stack trace of the errors, re-run Maven > with the > > -e switch. > > [ERROR] Re-run Maven using the -X switch to enable full debug > logging. > > [ERROR] > > [ERROR] For more information about the errors and possible solutions, > > please read the following articles: > > [ERROR] [Help 1] > > > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > > [ERROR] > > [ERROR] After correcting the problems, you can resume the build > with the > > command > > [ERROR] mvn -rf :wildfly-ts-integ-secman > > > > _______________________________________________ > > 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 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ewertz at redhat.com Thu Aug 28 08:37:28 2014 From: ewertz at redhat.com (Edward Wertz) Date: Thu, 28 Aug 2014 08:37:28 -0400 (EDT) Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <53FF098D.4060706@jboss.com> References: <53FF07A4.4060907@jboss.com> <53FF098D.4060706@jboss.com> Message-ID: <15219387.190.1409229442877.JavaMail.joe@localhost.localdomain> Question about the first point: Do the 'LDAPRealm' and 'ldap' authorization resources already exist when you're trying to do that command? I encountered a problem a few weeks ago regarding tab-completion where, after an '=', the complete fails if there are non-existent child resources in the path. I'm usually on EAP so it got pushed off my plate, but if that's the issue I'll look into it for Wildfly. Joe Wertz ----- Original Message ----- From: "Darran Lofthouse" To: "Darran Lofthouse" , wildfly-dev at lists.jboss.org Sent: Thursday, August 28, 2014 6:50:53 PM Subject: Re: [wildfly-dev] Two More CLI Nice To Haves On 28/08/14 11:42, Darran Lofthouse wrote: > Just suggesting a couple more items that would be nice to have in the CLI: - > > 1 - Tab completion at the following point: - > > ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= > > When adding there is only a finite number of child resources that can be > added. > > 2 - Show the default values for attributes displayed for tab completion: - > > [standalone at localhost:9999 / #] > ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( > attribute= base-dn= force= recursive= > user-dn-attribute= > > Anyway just a couple of ideas ;-) Or maybe at the point of adding the attribute name to the operation and pressing tab display the type, the default value and that attribute's description? > Regards, > Darran Lofthouse. > > > > _______________________________________________ > 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 Aug 28 08:48:32 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 28 Aug 2014 13:48:32 +0100 Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <15219387.190.1409229442877.JavaMail.joe@localhost.localdomain> References: <53FF07A4.4060907@jboss.com> <53FF098D.4060706@jboss.com> <15219387.190.1409229442877.JavaMail.joe@localhost.localdomain> Message-ID: <53FF2520.1080008@jboss.com> On 28/08/14 13:37, Edward Wertz wrote: > Question about the first point: > > Do the 'LDAPRealm' and 'ldap' authorization resources already exist when you're trying to do that command? I encountered a problem a few weeks ago regarding tab-completion where, after an '=', the complete fails if there are non-existent child resources in the path. At that point no they don't exist. > > I'm usually on EAP so it got pushed off my plate, but if that's the issue I'll look into it for Wildfly. > > Joe Wertz > > ----- Original Message ----- > From: "Darran Lofthouse" > To: "Darran Lofthouse" , wildfly-dev at lists.jboss.org > Sent: Thursday, August 28, 2014 6:50:53 PM > Subject: Re: [wildfly-dev] Two More CLI Nice To Haves > > > > On 28/08/14 11:42, Darran Lofthouse wrote: >> Just suggesting a couple more items that would be nice to have in the CLI: - >> >> 1 - Tab completion at the following point: - >> >> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= >> >> When adding there is only a finite number of child resources that can be >> added. >> >> 2 - Show the default values for attributes displayed for tab completion: - >> >> [standalone at localhost:9999 / #] >> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( >> attribute= base-dn= force= recursive= >> user-dn-attribute= >> >> Anyway just a couple of ideas ;-) > > Or maybe at the point of adding the attribute name to the operation and > pressing tab display the type, the default value and that attribute's > description? > >> Regards, >> Darran Lofthouse. >> >> >> >> _______________________________________________ >> 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 Aug 28 09:10:25 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 28 Aug 2014 14:10:25 +0100 Subject: [wildfly-dev] Renaming wildfly-sasl back to jboss-sasl Message-ID: <53FF2A41.2050703@jboss.com> Now that the SASL mechanisms have been moved from wildfly-sasl to wildfly-elytron I am going to rename the wildfly-sasl project back to jboss-sasl. At the same time I am going to rename the 1.x maintenance branch master. From this point on the jboss-sasl project will remain around for the purpose of creating 1.x maintenance releases but all upstream work will be in wildfly-elytron. The main reason for this notification is to point out that this means the history on master is not linear as it is being reset to a previous revision. Regards, Darran Lofthouse. From alexey.loubyansky at redhat.com Thu Aug 28 09:33:55 2014 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Thu, 28 Aug 2014 15:33:55 +0200 Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <53FF2520.1080008@jboss.com> References: <53FF07A4.4060907@jboss.com> <53FF098D.4060706@jboss.com> <15219387.190.1409229442877.JavaMail.joe@localhost.localdomain> <53FF2520.1080008@jboss.com> Message-ID: <53FF2FC3.6050607@redhat.com> On 08/28/2014 02:48 PM, Darran Lofthouse wrote: > On 28/08/14 13:37, Edward Wertz wrote: >> Question about the first point: >> >> Do the 'LDAPRealm' and 'ldap' authorization resources already exist when you're trying to do that command? I encountered a problem a few weeks ago regarding tab-completion where, after an '=', the complete fails if there are non-existent child resources in the path. > > At that point no they don't exist. What matters here is the model description. If it's available and accessible - no problem. The tool just reads it and offers choices. If it's not available to the tool, it cannot guess, unless it's gonna be hardcoded which I'd like to avoid. Alexey >> >> I'm usually on EAP so it got pushed off my plate, but if that's the issue I'll look into it for Wildfly. >> >> Joe Wertz >> >> ----- Original Message ----- >> From: "Darran Lofthouse" >> To: "Darran Lofthouse" , wildfly-dev at lists.jboss.org >> Sent: Thursday, August 28, 2014 6:50:53 PM >> Subject: Re: [wildfly-dev] Two More CLI Nice To Haves >> >> >> >> On 28/08/14 11:42, Darran Lofthouse wrote: >>> Just suggesting a couple more items that would be nice to have in the CLI: - >>> >>> 1 - Tab completion at the following point: - >>> >>> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= >>> >>> When adding there is only a finite number of child resources that can be >>> added. >>> >>> 2 - Show the default values for attributes displayed for tab completion: - >>> >>> [standalone at localhost:9999 / #] >>> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( >>> attribute= base-dn= force= recursive= >>> user-dn-attribute= >>> >>> Anyway just a couple of ideas ;-) >> >> Or maybe at the point of adding the attribute name to the operation and >> pressing tab display the type, the default value and that attribute's >> description? >> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> >>> _______________________________________________ >>> 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 alexey.loubyansky at redhat.com Thu Aug 28 10:04:43 2014 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Thu, 28 Aug 2014 16:04:43 +0200 Subject: [wildfly-dev] wildfly-core testsuite issues Message-ID: <53FF36FB.9070001@redhat.com> While moving the cli tests (those that can be) from the wildfly testsuite to the core, I stumbled upon a couple of puzzling issue which I don't see running the tests locally but the PR doesn't get a green light. One of them is maven-based module loading. Some of the tests start the CLI as a process providing all the command line arguments. These tests fail with Failed to resolve artifact 'org.wildfly.core:wildfly-cli:1.0.0.Alpha6-SNAPSHOT' Looks like it's not installed before the testsuite run. As a workaround, I, temporarily, pointed jboss.dist to core-dist/target/... The second problem is establishing a connection to the controller. Trying to connect, as in wildfly, using - http-remoting - TestSuiteEnvironment.getServerAddress() - TestSuiteEnvironment.getServerPort() fails with 'The controller is not available at [::1]:9990'. Any ideas how to fix this? Thanks, Alexey From brian.stansberry at redhat.com Thu Aug 28 11:05:48 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 28 Aug 2014 10:05:48 -0500 Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <53FF07A4.4060907@jboss.com> References: <53FF07A4.4060907@jboss.com> Message-ID: <53FF454C.1080703@redhat.com> Blatant thread hijack here, just to throw out an FYI about something that came up today that may also improve CLI experience: https://issues.jboss.org/browse/WFCORE-74 On 8/28/14, 5:42 AM, Darran Lofthouse wrote: > Just suggesting a couple more items that would be nice to have in the CLI: - > > 1 - Tab completion at the following point: - > > ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= > > When adding there is only a finite number of child resources that can be > added. > > 2 - Show the default values for attributes displayed for tab completion: - > > [standalone at localhost:9999 / #] > ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( > attribute= base-dn= force= recursive= > user-dn-attribute= > > Anyway just a couple of ideas ;-) > > 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 Thu Aug 28 12:42:09 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 28 Aug 2014 17:42:09 +0100 Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <53FF2FC3.6050607@redhat.com> References: <53FF07A4.4060907@jboss.com> <53FF098D.4060706@jboss.com> <15219387.190.1409229442877.JavaMail.joe@localhost.localdomain> <53FF2520.1080008@jboss.com> <53FF2FC3.6050607@redhat.com> Message-ID: <53FF5BE1.9010707@jboss.com> I have just blown away my server for a rebuild so can't check but it probably is a case that we are not exposing it in the model description, at that point the address is not valid so maybe that is something we should think about. Internally resources are registered with a final set of accepted values. On 28/08/14 14:33, Alexey Loubyansky wrote: > On 08/28/2014 02:48 PM, Darran Lofthouse wrote: >> On 28/08/14 13:37, Edward Wertz wrote: >>> Question about the first point: >>> >>> Do the 'LDAPRealm' and 'ldap' authorization resources already exist when you're trying to do that command? I encountered a problem a few weeks ago regarding tab-completion where, after an '=', the complete fails if there are non-existent child resources in the path. >> >> At that point no they don't exist. > > What matters here is the model description. If it's available and > accessible - no problem. The tool just reads it and offers choices. If > it's not available to the tool, it cannot guess, unless it's gonna be > hardcoded which I'd like to avoid. > > Alexey > >>> >>> I'm usually on EAP so it got pushed off my plate, but if that's the issue I'll look into it for Wildfly. >>> >>> Joe Wertz >>> >>> ----- Original Message ----- >>> From: "Darran Lofthouse" >>> To: "Darran Lofthouse" , wildfly-dev at lists.jboss.org >>> Sent: Thursday, August 28, 2014 6:50:53 PM >>> Subject: Re: [wildfly-dev] Two More CLI Nice To Haves >>> >>> >>> >>> On 28/08/14 11:42, Darran Lofthouse wrote: >>>> Just suggesting a couple more items that would be nice to have in the CLI: - >>>> >>>> 1 - Tab completion at the following point: - >>>> >>>> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= >>>> >>>> When adding there is only a finite number of child resources that can be >>>> added. >>>> >>>> 2 - Show the default values for attributes displayed for tab completion: - >>>> >>>> [standalone at localhost:9999 / #] >>>> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( >>>> attribute= base-dn= force= recursive= >>>> user-dn-attribute= >>>> >>>> Anyway just a couple of ideas ;-) >>> >>> Or maybe at the point of adding the attribute name to the operation and >>> pressing tab display the type, the default value and that attribute's >>> description? >>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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 Aug 28 12:44:26 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 28 Aug 2014 17:44:26 +0100 Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <53FF454C.1080703@redhat.com> References: <53FF07A4.4060907@jboss.com> <53FF454C.1080703@redhat.com> Message-ID: <53FF5C6A.1020904@jboss.com> I don't think it is a hijack ;-) But I do think it is a good sign that at the moment the main topics we have to talk about for the CLI are minor usability enhancements ;-) On 28/08/14 16:05, Brian Stansberry wrote: > Blatant thread hijack here, just to throw out an FYI about something > that came up today that may also improve CLI experience: > > https://issues.jboss.org/browse/WFCORE-74 > > > On 8/28/14, 5:42 AM, Darran Lofthouse wrote: >> Just suggesting a couple more items that would be nice to have in the CLI: - >> >> 1 - Tab completion at the following point: - >> >> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= >> >> When adding there is only a finite number of child resources that can be >> added. >> >> 2 - Show the default values for attributes displayed for tab completion: - >> >> [standalone at localhost:9999 / #] >> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( >> attribute= base-dn= force= recursive= >> user-dn-attribute= >> >> Anyway just a couple of ideas ;-) >> >> Regards, >> Darran Lofthouse. >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From brian.stansberry at redhat.com Thu Aug 28 12:56:20 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 28 Aug 2014 11:56:20 -0500 Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <53FF5BE1.9010707@jboss.com> References: <53FF07A4.4060907@jboss.com> <53FF098D.4060706@jboss.com> <15219387.190.1409229442877.JavaMail.joe@localhost.localdomain> <53FF2520.1080008@jboss.com> <53FF2FC3.6050607@redhat.com> <53FF5BE1.9010707@jboss.com> Message-ID: <53FF5F34.7020408@redhat.com> http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002701.html is likely relevant. These things are what Heiko described as "squatters", better name being "singletons". On 8/28/14, 11:42 AM, Darran Lofthouse wrote: > I have just blown away my server for a rebuild so can't check but it > probably is a case that we are not exposing it in the model description, > at that point the address is not valid so maybe that is something we > should think about. > > Internally resources are registered with a final set of accepted values. > > On 28/08/14 14:33, Alexey Loubyansky wrote: >> On 08/28/2014 02:48 PM, Darran Lofthouse wrote: >>> On 28/08/14 13:37, Edward Wertz wrote: >>>> Question about the first point: >>>> >>>> Do the 'LDAPRealm' and 'ldap' authorization resources already exist when you're trying to do that command? I encountered a problem a few weeks ago regarding tab-completion where, after an '=', the complete fails if there are non-existent child resources in the path. >>> >>> At that point no they don't exist. >> >> What matters here is the model description. If it's available and >> accessible - no problem. The tool just reads it and offers choices. If >> it's not available to the tool, it cannot guess, unless it's gonna be >> hardcoded which I'd like to avoid. >> >> Alexey >> >>>> >>>> I'm usually on EAP so it got pushed off my plate, but if that's the issue I'll look into it for Wildfly. >>>> >>>> Joe Wertz >>>> >>>> ----- Original Message ----- >>>> From: "Darran Lofthouse" >>>> To: "Darran Lofthouse" , wildfly-dev at lists.jboss.org >>>> Sent: Thursday, August 28, 2014 6:50:53 PM >>>> Subject: Re: [wildfly-dev] Two More CLI Nice To Haves >>>> >>>> >>>> >>>> On 28/08/14 11:42, Darran Lofthouse wrote: >>>>> Just suggesting a couple more items that would be nice to have in the CLI: - >>>>> >>>>> 1 - Tab completion at the following point: - >>>>> >>>>> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= >>>>> >>>>> When adding there is only a finite number of child resources that can be >>>>> added. >>>>> >>>>> 2 - Show the default values for attributes displayed for tab completion: - >>>>> >>>>> [standalone at localhost:9999 / #] >>>>> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( >>>>> attribute= base-dn= force= recursive= >>>>> user-dn-attribute= >>>>> >>>>> Anyway just a couple of ideas ;-) >>>> >>>> Or maybe at the point of adding the attribute name to the operation and >>>> pressing tab display the type, the default value and that attribute's >>>> description? >>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> 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 Thu Aug 28 13:02:05 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 28 Aug 2014 18:02:05 +0100 Subject: [wildfly-dev] Two More CLI Nice To Haves In-Reply-To: <53FF5F34.7020408@redhat.com> References: <53FF07A4.4060907@jboss.com> <53FF098D.4060706@jboss.com> <15219387.190.1409229442877.JavaMail.joe@localhost.localdomain> <53FF2520.1080008@jboss.com> <53FF2FC3.6050607@redhat.com> <53FF5BE1.9010707@jboss.com> <53FF5F34.7020408@redhat.com> Message-ID: <53FF608D.9040203@jboss.com> +1 that is exactly it. On 28/08/14 17:56, Brian Stansberry wrote: > http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002701.html is > likely relevant. These things are what Heiko described as "squatters", > better name being "singletons". > > On 8/28/14, 11:42 AM, Darran Lofthouse wrote: >> I have just blown away my server for a rebuild so can't check but it >> probably is a case that we are not exposing it in the model description, >> at that point the address is not valid so maybe that is something we >> should think about. >> >> Internally resources are registered with a final set of accepted values. >> >> On 28/08/14 14:33, Alexey Loubyansky wrote: >>> On 08/28/2014 02:48 PM, Darran Lofthouse wrote: >>>> On 28/08/14 13:37, Edward Wertz wrote: >>>>> Question about the first point: >>>>> >>>>> Do the 'LDAPRealm' and 'ldap' authorization resources already exist when you're trying to do that command? I encountered a problem a few weeks ago regarding tab-completion where, after an '=', the complete fails if there are non-existent child resources in the path. >>>> >>>> At that point no they don't exist. >>> >>> What matters here is the model description. If it's available and >>> accessible - no problem. The tool just reads it and offers choices. If >>> it's not available to the tool, it cannot guess, unless it's gonna be >>> hardcoded which I'd like to avoid. >>> >>> Alexey >>> >>>>> >>>>> I'm usually on EAP so it got pushed off my plate, but if that's the issue I'll look into it for Wildfly. >>>>> >>>>> Joe Wertz >>>>> >>>>> ----- Original Message ----- >>>>> From: "Darran Lofthouse" >>>>> To: "Darran Lofthouse" , wildfly-dev at lists.jboss.org >>>>> Sent: Thursday, August 28, 2014 6:50:53 PM >>>>> Subject: Re: [wildfly-dev] Two More CLI Nice To Haves >>>>> >>>>> >>>>> >>>>> On 28/08/14 11:42, Darran Lofthouse wrote: >>>>>> Just suggesting a couple more items that would be nice to have in the CLI: - >>>>>> >>>>>> 1 - Tab completion at the following point: - >>>>>> >>>>>> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn= >>>>>> >>>>>> When adding there is only a finite number of child resources that can be >>>>>> added. >>>>>> >>>>>> 2 - Show the default values for attributes displayed for tab completion: - >>>>>> >>>>>> [standalone at localhost:9999 / #] >>>>>> ./core-service=management/security-realm=LDAPRealm/authorization=ldap/username-to-dn=username-filter:add( >>>>>> attribute= base-dn= force= recursive= >>>>>> user-dn-attribute= >>>>>> >>>>>> Anyway just a couple of ideas ;-) >>>>> >>>>> Or maybe at the point of adding the attribute name to the operation and >>>>> pressing tab display the type, the default value and that attribute's >>>>> description? >>>>> >>>>>> Regards, >>>>>> Darran Lofthouse. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> _______________________________________________ >>> 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 frank.langelage at osnanet.de Thu Aug 28 19:29:46 2014 From: frank.langelage at osnanet.de (Frank Langelage) Date: Fri, 29 Aug 2014 01:29:46 +0200 Subject: [wildfly-dev] jboss-cli / management interface broken? Message-ID: <53FFBB6A.7040600@osnanet.de> Mmmh, what's this? New problem with WF 9 build from sources some minutes ago: + /mbi/tools/jboss/9.0/bin/jboss-cli.sh --controller=localhost:9990 --connect --user=jboss --password=xxx --file=/mbi/etc/mail-session.cli org.jboss.as.cli.CliInitializationException: Failed to connect to the controller at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278) at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:235) at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.modules.Module.run(Module.java:312) at org.jboss.modules.Main.main(Main.java:460) Caused by: org.jboss.as.cli.CommandLineException: Unable to authenticate against controller at localhost:9990 at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028) at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:846) at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825) at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276) ... 8 more Caused by: javax.security.sasl.SaslException: Authentication failed: the server presented no authentication mechanisms at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) at ...asynchronous invocation...(Unknown Source) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79) at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110) at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169) at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1020) ... 11 more org.jboss.as.cli.CliInitializationException: Failed to connect to the controller at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278) at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:235) at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.modules.Module.run(Module.java:312) at org.jboss.modules.Main.main(Main.java:460) Caused by: org.jboss.as.cli.CommandLineException: Unable to authenticate against controller at localhost:9990 at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028) at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:846) at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825) at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276) ... 8 more Caused by: javax.security.sasl.SaslException: Authentication failed: the server presented no authentication mechanisms at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) at ...asynchronous invocation...(Unknown Source) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79) at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110) at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169) at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1020) ... 11 more User has been added before with: $WILDFLY_HOME/bin/add-user.sh --user jboss --password xxx Check $JBOSS_HOME/bin/add-user.sh --user jboss --password xxx Updated user 'jboss' to file '/mbi/tools/jboss/9.0/standalone/configuration/mgmt-users.properties' 29.08. 01:23:29,942 INFO [org.jboss.as#logAdminConsole] WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management 29.08. 01:23:29,950 INFO [org.jboss.as#logAdminConsole] WFLYSRV0051: Admin console listening on http://0.0.0.0:9990 Starting web browser on localhost:9990 says: Your WildFly Application Server is running. However you have not yet added any users to be able to access the admin console. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140829/343d1988/attachment-0001.html From darran.lofthouse at jboss.com Fri Aug 29 06:57:52 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 29 Aug 2014 11:57:52 +0100 Subject: [wildfly-dev] jboss-cli / management interface broken? In-Reply-To: <53FFBB6A.7040600@osnanet.de> References: <53FFBB6A.7040600@osnanet.de> Message-ID: <54005CB0.5050901@jboss.com> Just had a clean build myself, added a user can can successfully authenticate for the admin console and the CLI. Maybe something is missing on your copy as it looks like you are using a server copied from the build. On 29/08/14 00:29, Frank Langelage wrote: > Mmmh, what's this? > > New problem with WF 9 build from sources some minutes ago: > > + /mbi/tools/jboss/9.0/bin/jboss-cli.sh --controller=localhost:9990 > --connect --user=jboss --password=xxx --file=/mbi/etc/mail-session.cli > org.jboss.as.cli.CliInitializationException: Failed to connect to the > controller > at > org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:235) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: org.jboss.as.cli.CommandLineException: Unable to authenticate > against controller at localhost:9990 > at > org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028) > at > org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:846) > at > org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825) > at > org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276) > ... 8 more > Caused by: javax.security.sasl.SaslException: Authentication failed: the > server presented no authentication mechanisms > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) > at > org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at > org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > at ...asynchronous invocation...(Unknown Source) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110) > at > org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) > at > org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) > at > org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at > org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169) > at > org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at > org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1020) > ... 11 more > org.jboss.as.cli.CliInitializationException: Failed to connect to the > controller > at > org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:235) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: org.jboss.as.cli.CommandLineException: Unable to authenticate > against controller at localhost:9990 > at > org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028) > at > org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:846) > at > org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825) > at > org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276) > ... 8 more > Caused by: javax.security.sasl.SaslException: Authentication failed: the > server presented no authentication mechanisms > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) > at > org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at > org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > at ...asynchronous invocation...(Unknown Source) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110) > at > org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) > at > org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) > at > org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at > org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169) > at > org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at > org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1020) > ... 11 more > > User has been added before with: > $WILDFLY_HOME/bin/add-user.sh --user jboss --password xxx > > Check > $JBOSS_HOME/bin/add-user.sh --user jboss --password xxx > Updated user 'jboss' to file > '/mbi/tools/jboss/9.0/standalone/configuration/mgmt-users.properties' > > > 29.08. 01:23:29,942 INFO [org.jboss.as#logAdminConsole] WFLYSRV0060: > Http management interface listening on http://0.0.0.0:9990/management > 29.08. 01:23:29,950 INFO [org.jboss.as#logAdminConsole] WFLYSRV0051: > Admin console listening on http://0.0.0.0:9990 > > Starting web browser on localhost:9990 says: > > > Your WildFly Application Server is running. > > However you have not yet added any users to be able to access the admin > console. > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jmesnil at redhat.com Fri Aug 29 08:34:24 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 29 Aug 2014 14:34:24 +0200 Subject: [wildfly-dev] Representation of boolean attribute in our XML configuration Message-ID: Out of curiosity, have we made a decision about the XML representation of boolean attributes in the next-generation of our management API? At the moment, we have 3 different styles: 1. as a empty element 2. as an attribute Mmmh, what's this? > > New problem with WF 9 build from sources some minutes ago: > > + /mbi/tools/jboss/9.0/bin/jboss-cli.sh --controller=localhost:9990 > --connect --user=jboss --password=xxx --file=/mbi/etc/mail-session.cli > org.jboss.as.cli.CliInitializationException: Failed to connect to the > controller > at > org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:235) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: org.jboss.as.cli.CommandLineException: Unable to > authenticate against controller at localhost:9990 > at > org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028) > at > org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:846) > at > org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825) > at > org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276) > ... 8 more > Caused by: javax.security.sasl.SaslException: Authentication failed: > the server presented no authentication mechanisms > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) > at > org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at > org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > at ...asynchronous invocation...(Unknown Source) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110) > at > org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) > at > org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) > at > org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at > org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169) > at > org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at > org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1020) > ... 11 more > org.jboss.as.cli.CliInitializationException: Failed to connect to the > controller > at > org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:235) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: org.jboss.as.cli.CommandLineException: Unable to > authenticate against controller at localhost:9990 > at > org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028) > at > org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:846) > at > org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825) > at > org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276) > ... 8 more > Caused by: javax.security.sasl.SaslException: Authentication failed: > the server presented no authentication mechanisms > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) > at > org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at > org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > at ...asynchronous invocation...(Unknown Source) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110) > at > org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) > at > org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) > at > org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at > org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169) > at > org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at > org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1020) > ... 11 more > > User has been added before with: > $WILDFLY_HOME/bin/add-user.sh --user jboss --password xxx > > Check > $JBOSS_HOME/bin/add-user.sh --user jboss --password xxx > Updated user 'jboss' to file > '/mbi/tools/jboss/9.0/standalone/configuration/mgmt-users.properties' > > > 29.08. 01:23:29,942 INFO [org.jboss.as#logAdminConsole] WFLYSRV0060: > Http management interface listening on http://0.0.0.0:9990/management > 29.08. 01:23:29,950 INFO [org.jboss.as#logAdminConsole] WFLYSRV0051: > Admin console listening on http://0.0.0.0:9990 > > Starting web browser on localhost:9990 says: > > > Your WildFly Application Server is running. > > However you have not yet added any users to be able to access the > admin console. > > > > > _______________________________________________ > 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/20140829/b081ed1a/attachment-0001.html From brian.stansberry at redhat.com Fri Aug 29 11:48:12 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 29 Aug 2014 10:48:12 -0500 Subject: [wildfly-dev] Representation of boolean attribute in our XML configuration In-Reply-To: References: Message-ID: <5400A0BC.7020106@redhat.com> On 8/29/14, 7:34 AM, Jeff Mesnil wrote: > Out of curiosity, have we made a decision about the XML representation of boolean attributes in the next-generation of our management API? > > At the moment, we have 3 different styles: > > 1. as a empty element Not this. This cannot support an expression. > 2. as an attribute jeff > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Fri Aug 29 11:59:58 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 29 Aug 2014 16:59:58 +0100 Subject: [wildfly-dev] jboss-cli / management interface broken? In-Reply-To: <54009200.5040304@osnanet.de> References: <53FFBB6A.7040600@osnanet.de> <54009200.5040304@osnanet.de> Message-ID: <5400A37E.5040408@jboss.com> We do need something more meaningful for the error message but out problem is that it is not a case of a single failure - using SASL for authentication after a failure it is still possible to try a further mechanism that succeeds. Just created this issue for the moment: - https://issues.jboss.org/browse/WFCORE-77 Regards, Darran Lofthouse. On 29/08/14 15:45, Frank Langelage wrote: > Here's the solution: > from running the testsuite there still was a running instance listening > on localhost:9990. > But I can start my instance which uses bind-address 0.0.0.0 without > problems in parallel. > > Then we have two listeners on the same port, but different hosts: > 127.0.0.1.9990 *.* 0 0 49152 0 LISTEN > *.9990 *.* 0 0 49152 0 LISTEN > > The mgmt user was added to my instance. > > But accessing localhost:9990 via browser or cli connects to the > testsuite instance where this user is not known. > > This exception and stacktrace is irritating. > A message like "Username not known or wrongs passwort" would be more > helpful in my eyes. > > Regards, Frank > > > On 29.08.14 01:29, Frank Langelage wrote: >> Mmmh, what's this? >> >> New problem with WF 9 build from sources some minutes ago: >> >> + /mbi/tools/jboss/9.0/bin/jboss-cli.sh --controller=localhost:9990 >> --connect --user=jboss --password=xxx --file=/mbi/etc/mail-session.cli >> org.jboss.as.cli.CliInitializationException: Failed to connect to the >> controller >> at >> org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278) >> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:235) >> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at org.jboss.modules.Module.run(Module.java:312) >> at org.jboss.modules.Main.main(Main.java:460) >> Caused by: org.jboss.as.cli.CommandLineException: Unable to >> authenticate against controller at localhost:9990 >> at >> org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028) >> at >> org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:846) >> at >> org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825) >> at >> org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276) >> ... 8 more >> Caused by: javax.security.sasl.SaslException: Authentication failed: >> the server presented no authentication mechanisms >> at >> org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) >> at >> org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) >> at >> org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) >> at >> org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) >> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) >> at ...asynchronous invocation...(Unknown Source) >> at >> org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) >> at >> org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) >> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) >> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) >> at >> org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79) >> at >> org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110) >> at >> org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) >> at >> org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) >> at >> org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) >> at >> org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169) >> at >> org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129) >> at >> org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) >> at >> org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) >> at >> org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1020) >> ... 11 more >> org.jboss.as.cli.CliInitializationException: Failed to connect to the >> controller >> at >> org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278) >> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:235) >> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at org.jboss.modules.Module.run(Module.java:312) >> at org.jboss.modules.Main.main(Main.java:460) >> Caused by: org.jboss.as.cli.CommandLineException: Unable to >> authenticate against controller at localhost:9990 >> at >> org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028) >> at >> org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:846) >> at >> org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825) >> at >> org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276) >> ... 8 more >> Caused by: javax.security.sasl.SaslException: Authentication failed: >> the server presented no authentication mechanisms >> at >> org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:388) >> at >> org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) >> at >> org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) >> at >> org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) >> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) >> at ...asynchronous invocation...(Unknown Source) >> at >> org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) >> at >> org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) >> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) >> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) >> at >> org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79) >> at >> org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110) >> at >> org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) >> at >> org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) >> at >> org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) >> at >> org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169) >> at >> org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129) >> at >> org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) >> at >> org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) >> at >> org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1020) >> ... 11 more >> >> User has been added before with: >> $WILDFLY_HOME/bin/add-user.sh --user jboss --password xxx >> >> Check >> $JBOSS_HOME/bin/add-user.sh --user jboss --password xxx >> Updated user 'jboss' to file >> '/mbi/tools/jboss/9.0/standalone/configuration/mgmt-users.properties' >> >> >> 29.08. 01:23:29,942 INFO [org.jboss.as#logAdminConsole] WFLYSRV0060: >> Http management interface listening on http://0.0.0.0:9990/management >> 29.08. 01:23:29,950 INFO [org.jboss.as#logAdminConsole] WFLYSRV0051: >> Admin console listening on http://0.0.0.0:9990 >> >> Starting web browser on localhost:9990 says: >> >> >> Your WildFly Application Server is running. >> >> However you have not yet added any users to be able to access the >> admin console. >> >> >> >> >> _______________________________________________ >> 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 ssilvert at redhat.com Fri Aug 29 13:17:42 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 29 Aug 2014 13:17:42 -0400 Subject: [wildfly-dev] No more metadata main? Message-ID: <5400B5B6.9070908@redhat.com> The org.jboss.metadata main module has gone away in WildFly 9. This used to include all the jboss metadata resources but has now been broken up. However, this breaks the Keycloak subsystem and any other module that used to reference it as a dependency. Should we restore this module for backward compatibility? Stan From ssilvert at redhat.com Fri Aug 29 13:19:15 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 29 Aug 2014 13:19:15 -0400 Subject: [wildfly-dev] No more metadata main? In-Reply-To: <5400B5B6.9070908@redhat.com> References: <5400B5B6.9070908@redhat.com> Message-ID: <5400B613.5090603@redhat.com> BTW, I don't mean put the resources back. I just mean should we have an aggregation module? On 8/29/2014 1:17 PM, Stan Silvert wrote: > The org.jboss.metadata main module has gone away in WildFly 9. This > used to include all the jboss metadata resources but has now been broken up. > > However, this breaks the Keycloak subsystem and any other module that > used to reference it as a dependency. Should we restore this module > for backward compatibility? > > Stan > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From stuart.w.douglas at gmail.com Fri Aug 29 16:38:43 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Sat, 30 Aug 2014 06:38:43 +1000 Subject: [wildfly-dev] No more metadata main? In-Reply-To: <5400B613.5090603@redhat.com> References: <5400B5B6.9070908@redhat.com> <5400B613.5090603@redhat.com> Message-ID: <5400E4D3.7060603@gmail.com> No objections here. Stuart Stan Silvert wrote: > BTW, I don't mean put the resources back. I just mean should we have an > aggregation module? > > On 8/29/2014 1:17 PM, Stan Silvert wrote: >> The org.jboss.metadata main module has gone away in WildFly 9. This >> used to include all the jboss metadata resources but has now been broken up. >> >> However, this breaks the Keycloak subsystem and any other module that >> used to reference it as a dependency. Should we restore this module >> for backward compatibility? >> >> Stan >> _______________________________________________ >> 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