[JBoss JIRA] (JGRP-1947) JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
by Justin Cranford (JIRA)
Justin Cranford created JGRP-1947:
-------------------------------------
Summary: JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
Key: JGRP-1947
URL: https://issues.jboss.org/browse/JGRP-1947
Project: JGroups
Issue Type: Bug
Affects Versions: 3.4.6
Environment: Java 7u80 x32
Tomcat 7.0.62
HA-JDBC 3.0.4-SNAPSHOT + JGroups 3.4.6
nmap 5.5.1
Reporter: Justin Cranford
Assignee: Bela Ban
I am running a two node Tomcat cluster. Both JGroups and Hazelcast are used for different parts of application clustering - JGroups for HA-JDBC, and Hazelcast for application locks outside of HA-JDBC.
Hazelcast is not relevant to JGroups, except I included the Hazelcast errors because they happen at the same time as the JGroups JGRP000006 errors. This gave me a hint of why I see JGRP000006, because the Hazelcast error is more specific about root cause.
Basically if I run a nmap TCP Connect scan on my servers like so, this opens/closes empty TCP connections. JGroups reports these events as JGRP000006, whereas Hazelcast reports them as "java.io.IOException[Connection reset by peer]".
I am wondering if JGroups can handle these nmap TCP Connect scans more gracefully, or even log a more descriptive error with the JGRP000006 error code.
My Tomcat errors for both JGroups and Hazelcast
Jul 31, 2015 12:27:52 AM com.hazelcast.nio.SocketAcceptor
INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Accepting socket connection from /10.0.0.86:40527
Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnectionManager
INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] 5900 accepted socket connection from /10.0.0.86:40527
Jul 31, 2015 12:27:52 AM org.jgroups.logging.JDKLogImpl warn
WARNING: JGRP000006: failed accepting connection from peer
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at java.io.DataInputStream.readFully(Unknown Source)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.readPeerAddress(TCPConnectionMap.java:494)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:376)
at org.jgroups.blocks.TCPConnectionMap$Acceptor.handleAccept(TCPConnectionMap.java:298)
at org.jgroups.blocks.TCPConnectionMap$Acceptor.run(TCPConnectionMap.java:282)
at java.lang.Thread.run(Unknown Source)
Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnection
INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Connection [/10.0.0.86:40527] lost. Reason: java.io.IOException[Connection reset by peer]
My nmap scan which triggers the JGRP000006 errors:
root@myserver:~$ nmap -n -T4 -sT -PN --max-scan-delay 0ms --min-rate 1000000 --max-retries 0 -p 443,3306,5900,7900,7901 10.0.0.85
Starting Nmap 5.51 ( http://nmap.org ) at 2015-07-31 01:33 UTC
Cannot find nmap-payloads. UDP payloads are disabled.
Nmap scan report for 10.0.0.85
Host is up (0.00035s latency).
PORT STATE SERVICE
443/tcp open https
3306/tcp open mysql
5900/tcp open vnc
7900/tcp open mevent
7901/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-841) Patching module testsuite failure
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-841?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-841:
---------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 2.0.0.Alpha12)
> Patching module testsuite failure
> ---------------------------------
>
> Key: WFCORE-841
> URL: https://issues.jboss.org/browse/WFCORE-841
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Environment: $ java -version
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> OS X Yosemite 10.10.4
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
> Fix For: 2.0.0.Beta1
>
>
> When running the core build locally , the 'patching' module testsuite fails:
> {code}
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
> Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Running org.jboss.as.patching.cli.PatchInspectUnitTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase
> testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase) Time elapsed: 0.044 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}>
> 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.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76)
> at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57)
> at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180)
> {code}
> If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order.
> Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround.
> The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-840) Improve API on AttributeDefinitions where a capability is referenced.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-840?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-840:
---------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 2.0.0.Alpha12)
> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
> Key: WFCORE-840
> URL: https://issues.jboss.org/browse/WFCORE-840
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha11
> Reporter: Darran Lofthouse
> Assignee: Tomaz Cerar
> Fix For: 2.0.0.Beta1
>
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-5040) DeltaSpike in WF 9.0.1 results in lots of warnings
by The Alchemist (JIRA)
The Alchemist created WFLY-5040:
-----------------------------------
Summary: DeltaSpike in WF 9.0.1 results in lots of warnings
Key: WFLY-5040
URL: https://issues.jboss.org/browse/WFLY-5040
Project: WildFly
Issue Type: Bug
Reporter: The Alchemist
Assignee: Jason Greene
{noformat}
21:59:01,315 INFO [org.jboss.weld.Event] (MSC service thread 1-2) WELD-000411: Observer method [BackedAnnotatedMethod] protected org.apache.deltaspike.core.impl.message.MessageBundleExtension.detectInterfaces(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
21:59:01,323 INFO [org.jboss.weld.Event] (MSC service thread 1-2) WELD-000411: Observer method [BackedAnnotatedMethod] protected org.apache.deltaspike.core.impl.exclude.extension.ExcludeExtension.vetoBeans(@Observes ProcessAnnotatedType<Object>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
21:59:01,324 INFO [org.jboss.weld.Event] (MSC service thread 1-2) WELD-000411: Observer method [BackedAnnotatedMethod] protected org.apache.deltaspike.core.impl.interceptor.GlobalInterceptorExtension.promoteInterceptors(@Observes ProcessAnnotatedType<Object>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
21:59:01,336 INFO [org.jboss.weld.Event] (MSC service thread 1-2) WELD-000411: Observer method [BackedAnnotatedMethod] public org.apache.deltaspike.security.impl.extension.SecurityExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
21:59:01,352 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.jmx.MBeanExtension activated=true
21:59:01,353 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.message.MessageBundleExtension activated=true
21:59:01,353 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.interceptor.GlobalInterceptorExtension activated=true
21:59:01,356 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.config.ConfigurationExtension activated=true
21:59:01,356 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.exception.control.extension.ExceptionControlExtension activated=true
21:59:01,362 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.exclude.extension.ExcludeExtension activated=true
21:59:01,362 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.exclude.CustomProjectStageBeanFilter activated=true
21:59:01,362 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.exclude.GlobalAlternative activated=true
21:59:01,363 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.core.impl.scope.DeltaSpikeContextExtension activated=true
21:59:01,363 INFO [org.apache.deltaspike.core.util.ClassDeactivationUtils] (MSC service thread 1-2) class: org.apache.deltaspike.security.impl.extension.SecurityExtension activated=true
21:59:01,909 WARN [org.jboss.weld.Validator] (MSC service thread 1-2) WELD-001478: Interceptor class org.apache.deltaspike.security.impl.extension.SecurityInterceptor is enabled for the application and for the bean archive whatever.ear/whatever.war/WEB-INF/classes. It will only be invoked in the @Priority part of the chain.
21:59:01,910 WARN [org.jboss.weld.Validator] (MSC service thread 1-2) WELD-001478: Interceptor class org.apache.deltaspike.security.impl.extension.SecurityInterceptor is enabled for the application and for the bean archive whatever.ear/whatever.war/WEB-INF/lib/deltaspike-security-module-impl-1.4.2.jar. It will only be invoked in the @Priority part of the chain.
21:59:01,937 WARN [org.jboss.weld.Bootstrap] (weld-worker-5) WELD-001125: Illegal bean type java.util.Comparator<javax.enterprise.inject.spi.AnnotatedConstructor<? super T>> ignored on [EnhancedAnnotatedTypeImpl] private static class org.apache.deltaspike.core.util.Annotateds$AnnotatedConstructorComparator
21:59:01,937 WARN [org.jboss.weld.Bootstrap] (weld-worker-4) WELD-001125: Illegal bean type java.util.Comparator<javax.enterprise.inject.spi.AnnotatedCallable<? super T>> ignored on [EnhancedAnnotatedTypeImpl] private static class org.apache.deltaspike.core.util.Annotateds$AnnotatedCallableComparator
21:59:01,935 WARN [org.jboss.weld.Bootstrap] (weld-worker-8) WELD-001125: Illegal bean type java.util.Comparator<javax.enterprise.inject.spi.AnnotatedField<? super T>> ignored on [EnhancedAnnotatedTypeImpl] private static class org.apache.deltaspike.core.util.Annotateds$AnnotatedFieldComparator
21:59:01,934 WARN [org.jboss.weld.Bootstrap] (weld-worker-1) WELD-001125: Illegal bean type java.util.Comparator<javax.enterprise.inject.spi.AnnotatedMethod<? super T>> ignored on [EnhancedAnnotatedTypeImpl] private static class org.apache.deltaspike.core.util.Annotateds$AnnotatedMethodComparator
21:59:01,945 WARN [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001125: Illegal bean type java.util.Comparator<org.apache.deltaspike.core.api.exception.control.HandlerMethod<?>> ignored on [EnhancedAnnotatedTypeImpl] public final class org.apache.deltaspike.core.impl.exception.control.ExceptionHandlerComparator
{noformat}
I'm not sure if these are meaningful or not. Is my app OK?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Jason Greene commented on WFLY-4937:
------------------------------------
Hi [~tomjenkinson],
Do you mean pausing existing distributed transactions? That's an interesting point to consider. IMO it seems reasonable to allow an existing distributed transaction to prepare + commit/rollback. However, interesting things happen if additional data modification changes originating from the external node happen on the suspended node as part of the overall work of that distributed transaction. They won't be allowed to proceed, so I imagine the transaction will rollback.
More explicitly I mean something like:
server A starts transaction
server A writes to local resource AR
server A calls server B's ejb doStuff
server B's doStuff writes to local resource BR and returns
server B is suspended
server A calls server B's ejb doOtherStuff
server B rejects the call throwing an exception
server A rolls the transaction back
resource AR changes are reverted
resource BR changes are reverted, even though the node is suspended
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.0.0.Alpha5
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 11.0.0.Alpha1
>
>
> We will handle suspend for JTA and JTS by disallowing new transactions and then block the suspend thread until the count of active transactions drops to zero. We will also suspend the recovery manager.
> We will *not* do graceful shutdown for the optional XTS subsystem. For example an incoming XTS request for an existing transaction will be blocked.
> Question: should we
> - raise a new JIRA for this XTS case;
> - document the deficiency and see if there are complaints;
> - document the deficiency and fix it in a subsequent release
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-4937:
-------------------------------
Parent: (was: WFLY-1247)
Issue Type: Feature Request (was: Sub-task)
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.0.0.Alpha5
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 10.0.0.Beta1
>
>
> We will handle suspend for JTA and JTS by disallowing new transactions and then block the suspend thread until the count of active transactions drops to zero. We will also suspend the recovery manager.
> We will *not* do graceful shutdown for the optional XTS subsystem. For example an incoming XTS request for an existing transaction will be blocked.
> Question: should we
> - raise a new JIRA for this XTS case;
> - document the deficiency and see if there are complaints;
> - document the deficiency and fix it in a subsequent release
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-4937:
-------------------------------
Fix Version/s: 11.0.0.Alpha1
(was: 10.0.0.Beta1)
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.0.0.Alpha5
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 11.0.0.Alpha1
>
>
> We will handle suspend for JTA and JTS by disallowing new transactions and then block the suspend thread until the count of active transactions drops to zero. We will also suspend the recovery manager.
> We will *not* do graceful shutdown for the optional XTS subsystem. For example an incoming XTS request for an existing transaction will be blocked.
> Question: should we
> - raise a new JIRA for this XTS case;
> - document the deficiency and see if there are complaints;
> - document the deficiency and fix it in a subsequent release
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months