[JBoss JIRA] (WFCORE-786) Remove temporary code to make compatible with WF core
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-786:
---------------------------------
Summary: Remove temporary code to make compatible with WF core
Key: WFCORE-786
URL: https://issues.jboss.org/browse/WFCORE-786
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 2.0.0.Alpha4
Some temporary code is needed in core to preserve compatibility with Wildfly following the work done on WFCORE-401. This should be removed and WildFly should be adjusted once this is all in a core release.
The changes are
* Common.xml's default constructor should be removed
* org.jboss.as.controller.resource.SocketBindingGroupResourceDefinition should be removed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-4827) Network Connection leak on client abort connection
by Andrea Bertolini (JIRA)
[ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.... ]
Andrea Bertolini commented on WFLY-4827:
----------------------------------------
Skipping tests I succeed in building jars. Now I'm going to test this new version.
> Network Connection leak on client abort connection
> --------------------------------------------------
>
> Key: WFLY-4827
> URL: https://issues.jboss.org/browse/WFLY-4827
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Sockets
> Affects Versions: 8.2.0.Final
> Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
> Reporter: Andrea Bertolini
> Assignee: Stuart Douglas
>
> We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
> Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored.
> To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.
> To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call.
> Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response.
> It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
> It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore).
> When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze.
> We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-4748) Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.... ]
Tomas Hofman reopened WFLY-4748:
--------------------------------
Hello Paul, this is still not quite working.
The @ViewChanged annotated method you added is not receiving any merge events, it only gets triggered after split.
I was poking around and found out that Infinispan have separate annotations @ViewChanged and @Merged and that only @Merged notifies about merge events. I tried to modify your fix and it works.
I'm attaching new PR, close it if I'm wrong please :): https://github.com/wildfly/wildfly/pull/7685
> Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4748
> URL: https://issues.jboss.org/browse/WFLY-4748
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
> Reporter: Tomas Hofman
> Assignee: Paul Ferraro
> Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1".
> This only happens after the second and other successive splits. After the first split both nodes execute the service correctly.
> After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'.
> I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted():
> {code}
> public void viewAccepted(View view) {
> // ...
> for (Listener listener: this.listeners) {
> listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView);
> }
> }
> {code}
> This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (JGRP-1919) SimpleChat example doesn't work
by Huy Nguyen (JIRA)
[ https://issues.jboss.org/browse/JGRP-1919?page=com.atlassian.jira.plugin.... ]
Huy Nguyen edited comment on JGRP-1919 at 7/1/15 3:20 AM:
----------------------------------------------------------
If you're on the latest osx yosemite, add the routing for IPv6 as follow:
{{sudo route add -inet6 default -interface en0}}
where en0 is the interface that has both inet and inet6 addresses.
This would allow you to use run the SimpleChat example without having to force it to use ipv4
was (Author: huyhnguyen):
If you're on the latest osx yosemite, add the routing for IPv6 as follow:
sudo route add -inet6 default -interface en0
where en0 is the interface that has both inet and inet6 addresses.
This would allow you to use run the SimpleChat example without having to force it to use ipv4
> SimpleChat example doesn't work
> -------------------------------
>
> Key: JGRP-1919
> URL: https://issues.jboss.org/browse/JGRP-1919
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.2
> Reporter: rama rama
> Assignee: Bela Ban
> Fix For: 3.4.8
>
>
> Hello,
> i have try to run SimpleChat.java class (provided on example) but it doesn't work... with version 3.6.2 i run two java but they doesn't 'connect' eachother..
> i got this error (if i use ipv4 the error persist, it change only the fact that is an ipv4 ip)
> ----
> WARNING: JGRP000034: iMac-di-Rama-78: failure sending message to /ff0e:0:0:0:0:8:8:8: java.io.IOException: No route to host
> ----
> version 3.4.8 isn't affected, and two process
> runned with this version connect and i can see the messages.
> Also, no error is displayed on 3.4.8
> just to avoid misunderstanding
> 1. i have read the other 'similar' message
> 2. i have try
> java org.jgroups.tests.McastReceiverTest +
> java org.jgroups.tests.McastSenderTest
> and work
> 3. i have try to use ipv4 and jgroups.bind_addr props
> what is strange is that with 3.4.8 the example work out of the box.
> os: osx
> java: 1.7.0_76
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (JGRP-1919) SimpleChat example doesn't work
by Huy Nguyen (JIRA)
[ https://issues.jboss.org/browse/JGRP-1919?page=com.atlassian.jira.plugin.... ]
Huy Nguyen commented on JGRP-1919:
----------------------------------
If you're on the latest osx yosemite, add the routing for IPv6 as follow:
sudo route add -inet6 default -interface en0
where en0 is the interface that has both inet and inet6 addresses.
This would allow you to use run the SimpleChat example without having to force it to use ipv4
> SimpleChat example doesn't work
> -------------------------------
>
> Key: JGRP-1919
> URL: https://issues.jboss.org/browse/JGRP-1919
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.2
> Reporter: rama rama
> Assignee: Bela Ban
> Fix For: 3.4.8
>
>
> Hello,
> i have try to run SimpleChat.java class (provided on example) but it doesn't work... with version 3.6.2 i run two java but they doesn't 'connect' eachother..
> i got this error (if i use ipv4 the error persist, it change only the fact that is an ipv4 ip)
> ----
> WARNING: JGRP000034: iMac-di-Rama-78: failure sending message to /ff0e:0:0:0:0:8:8:8: java.io.IOException: No route to host
> ----
> version 3.4.8 isn't affected, and two process
> runned with this version connect and i can see the messages.
> Also, no error is displayed on 3.4.8
> just to avoid misunderstanding
> 1. i have read the other 'similar' message
> 2. i have try
> java org.jgroups.tests.McastReceiverTest +
> java org.jgroups.tests.McastSenderTest
> and work
> 3. i have try to use ipv4 and jgroups.bind_addr props
> what is strange is that with 3.4.8 the example work out of the box.
> os: osx
> java: 1.7.0_76
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (DROOLS-833) PermGen issue with Kie CI
by C R (JIRA)
C R created DROOLS-833:
--------------------------
Summary: PermGen issue with Kie CI
Key: DROOLS-833
URL: https://issues.jboss.org/browse/DROOLS-833
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.2.0.Final
Environment: RHEL 6.5, JDK 1.7.0_71, Wildfly 8.2, Sonatype Nexus 2.11.3-0
Reporter: C R
Assignee: Mario Fusco
We're facing a lot of issues with permgen OOM errors while using the KIE CI implementation to get the rules during runtime from a Nexus host.
A jmap analysis shows that 414MB of dead permgen is produced by org/eclipse/sisu/space/CloningClassSpace$CloningClassLoader@0x00000007ef60b6a0
With a dependency tree analysis it's shown, that only kie CI uses the sisu classes:
+- org.kie:kie-ci:jar:6.2.0.Final:compile
[INFO] | +- org.apache.maven:maven-artifact:jar:3.2.2:compile
[INFO] | +- org.apache.maven:maven-core:jar:3.2.2:compile
[INFO] | | +- org.apache.maven:maven-repository-metadata:jar:3.2.2:compile
[INFO] | | +- org.codehaus.plexus:plexus-interpolation:jar:1.19:compile
[INFO] | | +- org.codehaus.plexus:plexus-component-annotations:jar:1.5.5:compile
[INFO] | | \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
[INFO] | +- org.apache.maven:maven-model:jar:3.2.2:compile
[INFO] | +- org.apache.maven:maven-model-builder:jar:3.2.2:compile
[INFO] | +- org.apache.maven:maven-plugin-api:jar:3.2.2:compile
[INFO] | +- org.apache.maven:maven-settings:jar:3.2.2:compile
[INFO] | +- org.apache.maven:maven-settings-builder:jar:3.2.2:compile
[INFO] | +- org.apache.maven:maven-compat:jar:3.2.2:compile
[INFO] | +- org.apache.maven:maven-aether-provider:jar:3.2.2:compile
[INFO] | +- org.apache.maven.wagon:wagon-provider-api:jar:1.0:compile
[INFO] | +- org.codehaus.plexus:plexus-classworlds:jar:2.5.1:compile
[INFO] | +- org.codehaus.plexus:plexus-utils:jar:3.0.17:compile
[INFO] | +- org.eclipse.aether:aether-api:jar:1.0.0.v20140518:compile
[INFO] | +- org.eclipse.aether:aether-util:jar:1.0.0.v20140518:compile
[INFO] | +- org.eclipse.aether:aether-impl:jar:1.0.0.v20140518:compile
[INFO] | +- org.eclipse.aether:aether-connector-basic:jar:1.0.0.v20140518:compile
[INFO] | +- org.eclipse.aether:aether-spi:jar:1.0.0.v20140518:compile
[INFO] | +- org.eclipse.aether:aether-transport-wagon:jar:1.0.0.v20140518:compile
[INFO] | +- org.eclipse.aether:aether-transport-file:jar:1.0.0.v20140518:compile
[INFO] | +- org.eclipse.aether:aether-transport-http:jar:1.0.0.v20140518:compile
[INFO] | | \- org.slf4j:jcl-over-slf4j:jar:1.6.2:compile
[INFO] | +- org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5:compile
[INFO] | | \- org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.0.0.M5:compile
[INFO] | +- org.apache.ant:ant:jar:1.8.2:compile
[INFO] | | \- org.apache.ant:ant-launcher:jar:1.8.2:compile
[INFO] | +- org.apache.maven.wagon:wagon-http:jar:2.0:compile
[INFO] | | \- org.apache.maven.wagon:wagon-http-shared4:jar:2.0:compile
[INFO] | | \- org.jsoup:jsoup:jar:1.6.1:compile
[INFO] | +- org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[INFO] | \- org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:compile
[INFO] | \- aopalliance:aopalliance:jar:1.0:compile
The most current version of the sisu implementation is 0.3.1 while kie-ci is using 0.0.0.M5. Maybe this is related to a bug in sisu with this old version.
Is it possible to include a newer version of sisu with ki-ci?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-4844) When Wildfly EJB timer finishes, the transaction is not fully committed.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4844?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4844:
------------------------------------
Assignee: Stuart Douglas
> When Wildfly EJB timer finishes, the transaction is not fully committed.
> -------------------------------------------------------------------------
>
> Key: WFLY-4844
> URL: https://issues.jboss.org/browse/WFLY-4844
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Environment: Ubuntu and Mac
> Reporter: xiaodong xie
> Assignee: Stuart Douglas
> Priority: Critical
>
> When a Singleton EJB timer finishes, if the next run has already started but waiting on the write lock of Singleton EJB, the next run won't see the changes committed by the current run. So I assume when the EJB timers finishes, the transaction is not fully committed, or it's the next run that starts too early.
> Here is a test case that should be able to reproduce the issue we are facing.
> https://github.com/xiaodong-xie/wildfly-singleton-timer
> Here is my analysis of this issue:
> The CMTTxInterceptor is applied before ContainerManagedConcurrencyInterceptor.
> So when waiting for the write lock of EJBReadWriteLock, we've already started the transaction, which IMHO is earlier than necessary.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-4846) Unable to create vault
by Sören Dierkes (JIRA)
[ https://issues.jboss.org/browse/WFLY-4846?page=com.atlassian.jira.plugin.... ]
Sören Dierkes edited comment on WFLY-4846 at 7/1/15 1:41 AM:
-------------------------------------------------------------
I found a "resolution". If the storepass is EQUAL to the keypass it works.
But I guess it is he wrong place anyways and can be closed/moved.
was (Author: majin):
I found a "resolution". If the storepass is EQUAL to the keypass it works.
But I guess it ist he wrong place anyways and can be closed/moved.
> Unable to create vault
> ----------------------
>
> Key: WFLY-4846
> URL: https://issues.jboss.org/browse/WFLY-4846
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.0.CR2
> Reporter: Sören Dierkes
> Assignee: Darran Lofthouse
>
> I was unable to create a vault with the current release.
> The last version I've tried and which works was 8.2.0 with Java 8
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months