JBoss Developer: Message ListMost recent forum messageshttps://developer.jboss.org/?view=discussionsJive Engage2017-05-18T20:57:51Z2017-05-18T20:57:51ZenRe: Best way to get thread dump from wildfly running as a Windows service (wildfly-servicexe/ apache procrun)Rich DiCroce/people/rcddo-not-reply@jboss.com2017-05-18T20:57:51Z2017-05-18T20:57:51Z<!-- [DocumentBodyStart:34f0c417-bd58-4897-89c3-b55fd2dfa9b6] --><div class="jive-rendered-content"><p>I typically use JVisualVM, which is currently shipped as part of the JDK but apparently will be separate starting with JDK 9.</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>There are two fairly easy ways to connect JVisualVM to WF when WF is running as a service.</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>1) Configure the service to log on as some user account instead of as the Local System account. Then if you log on to the machine using the same account, the WF process will be visible.</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>2) WF exposes JMX over its HTTP port, unless you've changed your WF config to stop it from doing that. You can use this to access WF running as any user.</p><p>Start JVisualVM with the cli-client JAR on the classpath:</p><p><strong>jvisualvm --cp:a $WFLY\bin\client\jboss-cli-client.jar</strong></p><p>Then go to File -&gt; Add JMX Connection. In the connection field, enter:</p><p><strong>service:jmx:remote+<span class="external-link"><a class="jive-link-external-small" href="http://localhost:$PORT" rel="nofollow">http://localhost:$PORT</a></span><br/></strong>where $PORT is the port defined in the WildFly configuration file for the management-http socket-binding (9990 by default).</p></div><!-- [DocumentBodyEnd:34f0c417-bd58-4897-89c3-b55fd2dfa9b6] --><img src='/beacon?t=1519283758625' />2017-05-18T20:57:51Z9 months 5 days ago0Re: WildFly - PostgreSQL Non-XA DS - relation does not existRich DiCroce/people/rcddo-not-reply@jboss.com2016-10-18T21:11:17Z2016-10-18T21:11:17Z<!-- [DocumentBodyStart:878d71f6-a7cf-48b7-bc1f-59d163d8164b] --><div class="jive-rendered-content"><p>You might be getting hit by WFLY-6157.</p></div><!-- [DocumentBodyEnd:878d71f6-a7cf-48b7-bc1f-59d163d8164b] -->2016-10-18T21:11:17Z1 year 4 months ago0Re: Version and patch strategy with wildflyRich DiCroce/people/rcddo-not-reply@jboss.com2016-08-25T20:59:54Z2016-08-25T20:59:54Z<!-- [DocumentBodyStart:ff6a6183-40ea-4419-a431-72ef46707e55] --><div class="jive-rendered-content"><p>As I understand it:</p><ul><li>WildFly version number is not tied to EE version.</li><li>WildFly is a community project. The official policy is that only the current major release gets patches. Unofficially, previous major releases sometimes get patched if the TPTB feel like it. I wouldn't depend on that happening though. If you need a guarantee, you should be using JBoss EAP.</li><li>WildFly follows semver rules, so minor releases should be backwards-compatible, but major releases may not be. Of course, all releases are certified against the EE TCK, so practically speaking, backwards compatibility is only something you have to worry about if you depend on functionality that is not mandated by some EE spec.</li></ul></div><!-- [DocumentBodyEnd:ff6a6183-40ea-4419-a431-72ef46707e55] -->2016-08-25T20:59:54Z1 year 6 months ago0Re: mysql datasource in wildfly-10.0.0Rich DiCroce/people/rcddo-not-reply@jboss.com2016-04-26T19:37:36Z2016-04-26T19:37:36Z<!-- [DocumentBodyStart:241b6e9d-05cf-4b10-98af-1a758203c767] --><div class="jive-rendered-content"><p>Does your configuration have datasource-class defined? If yes, then you are probably affected by WFLY-6157. The comments on that issue explain how to fix the problem.</p></div><!-- [DocumentBodyEnd:241b6e9d-05cf-4b10-98af-1a758203c767] -->2016-04-26T19:37:36Z1 year 10 months ago10Re: Too many intra-process localhost connectionsRich DiCroce/people/rcddo-not-reply@jboss.com2016-04-11T21:25:41Z2016-04-11T21:25:41Z<!-- [DocumentBodyStart:3e67f7b9-340a-4e6c-aa18-72f17e2a023c] --><div class="jive-rendered-content"><p>Does your application use java.io.PipedInput/OutputStream? If memory serves, those are implemented using loopback sockets on Windows. Most likely something in WildFly is also using them, which leads to a bunch of loopback sockets being created when the server starts up.</p></div><!-- [DocumentBodyEnd:3e67f7b9-340a-4e6c-aa18-72f17e2a023c] -->2016-04-11T21:25:41Z1 year 10 months ago0Re: How to detect Wildfly versionRich DiCroce/people/rcddo-not-reply@jboss.com2015-11-18T22:30:44Z2015-11-18T22:30:44Z<!-- [DocumentBodyStart:66b66cd2-d5d0-4530-801a-cb4096a0e4fa] --><div class="jive-rendered-content"><p>Indeed, the module org.jboss.as.version is marked as private, and recent versions of WildFly will log warnings if your deployment uses it. Fortunately, there is another way to obtain the version using JMX that requires no additional dependencies.</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>Use java.lang.management.ManagementFactory#getPlatformMBeanServer() to obtain a MBeanServer, then perform a lookup on object name "jboss.as:management-root=server", attribute "productVersion". This will return the WildFly Full version. There is another attribute (can't remember the name of it) that returns the WildFly Core version, if you're interested in that. Our code does this and it works great, currently running on WildFly 10.0.0.CR2.</p></div><!-- [DocumentBodyEnd:66b66cd2-d5d0-4530-801a-cb4096a0e4fa] -->2015-11-18T22:30:44Z2 years 3 months ago0Re: start process of WildFly-8.2.0-Final never finish (Starting, Synchronized)Rich DiCroce/people/rcddo-not-reply@jboss.com2015-10-27T20:51:20Z2015-10-27T20:51:20Z<!-- [DocumentBodyStart:ee47bc70-291b-4f87-9881-8efecaf14065] --><div class="jive-rendered-content"><p>My co-workers and I see this from time to time. Double-click on the server in the Servers tab and look at how the Server State Detectors are set. Your pollers should be set to Web Port or Management Service. Then check the Server Ports and make sure the ports are being detected correctly. Change them if not.</p></div><!-- [DocumentBodyEnd:ee47bc70-291b-4f87-9881-8efecaf14065] -->2015-10-27T20:51:20Z2 years 4 months ago100Re: Partition handling and event listenersRich DiCroce/people/rcddo-not-reply@jboss.com2015-09-09T21:36:32Z2015-09-09T21:36:32Z<!-- [DocumentBodyStart:46b2836b-e37a-473e-b1f6-5ecf8a9b4f30] --><div class="jive-rendered-content"><p>Since nobody weighed in here, I did some experiments using WildFly 10.0.0.Beta2, which bundles Infinispan 8.0.0.CR1.</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>The answer (at least for a replicated mode cache) is that events are fired, but not the same events that would normally occur during a remove(). Instead, on the node(s) that get wiped, a TopologyChangedEvent is fired, followed by a CacheEntryInvalidatedEvent for every entry currently in the cache. Then a DataRehashedEvent is fired, followed by two CacheEntryCreatedEvents (one with pre = true, and another with pre = false) for each entry obtained from the other partition. (There are also a bunch more TopologyChangedEvents mixed in. I'm not sure why there are so many but it's irrelevant to this discussion anyway.)</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>So the bottom line is: yes, Infinispan will call your listeners but you need to listen for the right events.</p></div><!-- [DocumentBodyEnd:46b2836b-e37a-473e-b1f6-5ecf8a9b4f30] -->2015-09-09T21:36:32Z2 years 5 months ago0Partition handling and event listenersRich DiCroce/people/rcddo-not-reply@jboss.com2015-09-08T18:35:38Z2015-09-08T18:35:38Z<!-- [DocumentBodyStart:0be5d5ee-a5cc-473d-a178-3830e5805cc0] --><div class="jive-rendered-content"><p>We have an application that currently runs on WildFly 8 and uses the bundled Infinispan 6. Unsurprisingly, this application has some problems dealing with network partitions because Infinispan 6's approach to handling partitions was basically to stick its fingers in its ears and yell "LALALALA I CAN'T HEAR YOU!"</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>Infinispan 7 added proper handling of partitions. In terms of the CAP theorem, we want an AP cluster because a temporary lack of consistency doesn't matter much, but we do need the cluster to continue operating even if most of it abruptly dies. So I've been investigating what Infinispan will do when configured for availability. The best information I've been able to find is <a class="jive-link-external-small" href="https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-Infinispan" rel="nofollow">this page</a> on the GitHub wiki, which states:</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><blockquote class="jive-quote">
<p>When the partitions merge, Infinispan does not attempt to merge the different values that each partition might have. The largest partition (i.e. the one with the most nodes) is assumed to be the correct one, and its topology becomes the <strong>merge topology</strong>. Data from nodes not in the merge CH is wiped, and they will receive the latest data from nodes in the merge CH.</p>
</blockquote><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>That's from section 3.1.2, talking about replicated caches, but the section for distributed caches says pretty much the same thing. As detailed as that document is, it doesn't cover what happens with event listeners, and we use listeners quite heavily.</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>So my question is: when two partitions merge and the nodes in one partition wipe out all their data, will the nodes in that partition call event listeners on the caches? As an example scenario, suppose node A in partition 1 has a cache containing the key-value pair (X, Y). Then the partition heals. Node A detects that partition 2 has more nodes, so it wipes its cache and reacquires the state from one of the nodes in partition 2. But in partition 2, the key X had no mapping, so after reacquiring the state, node A still doesn't have a mapping for X. From the application's standpoint, this is equivalent to the mapping being removed from the cache. A normal remove() operation would trigger a CacheEntryRemovedEvent to be delivered the relevant listeners. Will that still happen when a partition heals as in this scenario?</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>And now for a side rant: why is the partition-handling configuration option a boolean? The quote above describes Infinispan's behavior with partition handling "disabled" (i.e. partition-handling = false), but as far as I'm concerned, "biggest partition wins" is a perfectly valid strategy for handling partitions. To me, partition handling being disabled implies Infinispan 6's behavior: the cluster literally does nothing about it. The partition-handling option isn't really about <em>whether</em> partitions are handled but rather <em>how</em> they are handled: false gives you an AP system versus true gives you a CP system. This greatly confused me when I first started reading about the partition handling changes.</p></div><!-- [DocumentBodyEnd:0be5d5ee-a5cc-473d-a178-3830e5805cc0] -->2015-09-08T18:35:38Z2 years 5 months ago10Re: Best way to shutdown Wildfly from within my deploymentRich DiCroce/people/rcddo-not-reply@jboss.com2015-02-27T22:27:41Z2015-02-27T22:27:41Z<!-- [DocumentBodyStart:5eb775d7-4dbf-4674-97f0-f7ccba61f860] --><div class="jive-rendered-content"><p>I've done it using JMX. No extra dependencies required. Code snippets:</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>SHUTDOWN_SIGNATURE = new String[] {boolean.class.getName()};</p><p>mbeanServer = ManagementFactory.getPlatformMBeanServer();</p><p>jmxServerObjectName = new ObjectName("jboss.as:management-root=server");</p><p>mbeanServer.invoke(jmxServerObjectName, "shutdown",</p><p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; new Object[] {false}, SHUTDOWN_SIGNATURE);</p><p style="min-height: 8pt; padding: 0px;">&#160;</p><p>All classes used above are part of the JDK. The boolean parameter in the Object array indicates whether you want to restart WildFly after shutting it down. If you need to do anything else, the whole management API is exposed through JMX, so anything listed at <a class="jive-link-external-small" href="http://wildscribe.github.io/" rel="nofollow">http://wildscribe.github.io/</a> is available.</p></div><!-- [DocumentBodyEnd:5eb775d7-4dbf-4674-97f0-f7ccba61f860] -->2015-02-27T22:27:41Z2 years 12 months ago0