[JBoss JIRA] (JBAS-9549) The UDP port opened for all IPs in the JBoss 7 standalone configuration
by Michael Furman (JIRA)
[ https://issues.jboss.org/browse/JBAS-9549?page=com.atlassian.jira.plugin.... ]
Michael Furman updated JBAS-9549:
---------------------------------
Description:
The bug is for Jboss 7.1.1.Final (I was not able to select it when I opened the issue)
I launched Jboss 7.1.1.Final on Centos6 using JDK7.
When I check what ports are opened I see the following UDP port opened for all IPs:
netstat -ntulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 :::43676 :::* 2460/java
The port is changing its value each time I restart JBoss.
Where and why the UDP port is configured?
I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
I still can see opened UDP port and I want to close it.
was:
The bug is for Jboss 7.1.1.Final (I was not able to select it when I opened the issue)
I launched Jboss 7.1.1.Final on Centos6 using JDK7.
When I check what port is opened I see the following UDP port opened for all IPs:
netstat -ntulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 :::43676 :::* 2460/java
The port is changing its value each time I restart JBoss.
Where and why the UDP port is configured?
I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
I still can see opened UDP port and I want to close it.
> The UDP port opened for all IPs in the JBoss 7 standalone configuration
> -----------------------------------------------------------------------
>
> Key: JBAS-9549
> URL: https://issues.jboss.org/browse/JBAS-9549
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Michael Furman
> Assignee: Anil Saldhana
>
> The bug is for Jboss 7.1.1.Final (I was not able to select it when I opened the issue)
> I launched Jboss 7.1.1.Final on Centos6 using JDK7.
> When I check what ports are opened I see the following UDP port opened for all IPs:
>
> netstat -ntulp
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
> udp 0 0 :::43676 :::* 2460/java
>
> The port is changing its value each time I restart JBoss.
> Where and why the UDP port is configured?
>
> I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
>
> I still can see opened UDP port and I want to close it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBAS-9549) The UDP port opened for all IPs in the JBoss 7 standalone configuration
by Michael Furman (JIRA)
[ https://issues.jboss.org/browse/JBAS-9549?page=com.atlassian.jira.plugin.... ]
Michael Furman updated JBAS-9549:
---------------------------------
Description:
The bug is for Jboss 7.1.1.Final (I was not able to select it when I opened the issue)
I launched Jboss 7.1.1.Final on Centos6 using JDK7.
When I check what port is opened I see the following UDP port opened for all IPs:
netstat -ntulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 :::43676 :::* 2460/java
The port is changing its value each time I restart JBoss.
Where and why the UDP port is configured?
I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
I still can see opened UDP port and I want to close it.
was:
The bug is for Jboss 7.1.1.Final (I was not able to select it when I open the issue)
I launched Jboss 7.1.1.Final on Centos6 using JDK7.
When I check what port is opened I see the following UDP port opened for all IPs:
netstat -ntulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 :::43676 :::* 2460/java
The port is changing its value each time I restart JBoss.
Where and why the UDP port is configured?
I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
I still can see opened UDP port and I want to close it.
> The UDP port opened for all IPs in the JBoss 7 standalone configuration
> -----------------------------------------------------------------------
>
> Key: JBAS-9549
> URL: https://issues.jboss.org/browse/JBAS-9549
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Michael Furman
> Assignee: Anil Saldhana
>
> The bug is for Jboss 7.1.1.Final (I was not able to select it when I opened the issue)
> I launched Jboss 7.1.1.Final on Centos6 using JDK7.
> When I check what port is opened I see the following UDP port opened for all IPs:
>
> netstat -ntulp
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
> udp 0 0 :::43676 :::* 2460/java
>
> The port is changing its value each time I restart JBoss.
> Where and why the UDP port is configured?
>
> I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
>
> I still can see opened UDP port and I want to close it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBAS-9549) The UDP port opened for all IPs in the JBoss 7 standalone configuration
by Michael Furman (JIRA)
Michael Furman created JBAS-9549:
------------------------------------
Summary: The UDP port opened for all IPs in the JBoss 7 standalone configuration
Key: JBAS-9549
URL: https://issues.jboss.org/browse/JBAS-9549
Project: Application Server 3 4 5 and 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Reporter: Michael Furman
Assignee: Anil Saldhana
The bug is for Jboss 7.1.1.Final (I was not able to select it when I open the issue)
I launched Jboss 7.1.1.Final on Centos6 using JDK7.
When I check what port is opened I see the following UDP port opened for all IPs:
netstat -ntulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 :::43676 :::* 2460/java
The port is changing its value each time I restart JBoss.
Where and why the UDP port is configured?
I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
I still can see opened UDP port and I want to close it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-674) NPE in thread "vfs-shutdown"
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-674?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar resolved WFLY-674.
------------------------------
Fix Version/s: 8.0.0.Beta1
(was: 8.0.0.CR1)
Resolution: Done
> NPE in thread "vfs-shutdown"
> -----------------------------
>
> Key: WFLY-674
> URL: https://issues.jboss.org/browse/WFLY-674
> Project: WildFly
> Issue Type: Bug
> Components: VFS
> Environment: 7.1.0.Alpha1 Jenkins build 1402
> Reporter: Juergen Zimmermann
> Assignee: David Lloyd
> Fix For: 8.0.0.Beta1
>
>
> When I shutdown a standalone server I'm getting a NPE. The shutdown command is:
> jboss-admin.bat --connect command=:shutdown
> Console log:
> ...
> 18:24:55,990 INFO [org.jboss.as.logging] Restored bootstrap log handlers
> 18:24:55,990 INFO [org.jboss.as.jmx.JMXConnectorService] JMX remote connector stopped
> 18:24:56,075 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-as-osgi-configadmin:7.1.0.Alpha1-SNAPSHOT
> 18:24:56,125 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.log:1.0.0
> 18:24:56,230 INFO [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
> 18:24:56,286 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.configadmin:1.2.8
> 18:24:56,323 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-osgi-logging:1.0.0
> 18:24:56,330 INFO [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
> 18:24:56,331 INFO [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
> 18:24:56,368 ERROR [stderr] Exception in thread "vfs-shutdown" java.lang.NullPointerException
> 18:24:56,368 ERROR [stderr] at org.jboss.vfs.TempFileProvider$DeleteTask.run(TempFileProvider.java:151)
> 18:24:56,368 ERROR [stderr] at org.jboss.vfs.TempFileProvider.close(TempFileProvider.java:132)
> 18:24:56,368 ERROR [stderr] at org.jboss.osgi.vfs30.VirtualFileAdaptor30$2.run(VirtualFileAdaptor30.java:94)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-11) Bundle path for Embedded server still not working properly
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-11?page=com.atlassian.jira.plugin.sy... ]
Jason Greene updated WFLY-11:
-----------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Bundle path for Embedded server still not working properly
> ----------------------------------------------------------
>
> Key: WFLY-11
> URL: https://issues.jboss.org/browse/WFLY-11
> Project: WildFly
> Issue Type: Bug
> Reporter: Galder Zamarreño
> Assignee: Alexey Loubyansky
> Fix For: 8.0.0.CR1
>
>
> Error is:
> {code} io.escalante.test.artifact.ArtifactInstallTest: bundlesDir not a directory{code}
> The problem is that the check is done in an 'assert' block and that only happens when assertions have been enabled by the user :(
> The problem comes cos bundlesDir is set to "null/bundles", even if I have not set any bundlesDir.
> Seems like bundlesDir is pre-computed too early in EmbeddedContainerConfiguration where it expects a system property, but that might not be set, it might come from arquillian.xml. So better delay until EmbeddedServerFactory.create.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-8) [PassivateTask] null: java.lang.NullPointerException
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-8?page=com.atlassian.jira.plugin.sys... ]
Jason Greene updated WFLY-8:
----------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> [PassivateTask] null: java.lang.NullPointerException
> ----------------------------------------------------
>
> Key: WFLY-8
> URL: https://issues.jboss.org/browse/WFLY-8
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Fix For: 8.0.0.CR1
>
> Attachments: server.log
>
>
> Going through the server logs from clustering testsuite suspicious NPE on INFO caught my eye. Seems like an edge case not being covered.
> Affected version: master 8a6aac3c8eb6bc94b7eddfa4d090c9ac05c7e37b
> {code}
> 15:10:57,385 INFO [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-17-thread-1) null: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.prePassivate(StatefulSessionComponent.java:157) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.prePassivate(StatefulSessionComponent.java:73) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.prePassivate(SerializationGroupMemberContainer.java:165) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.prePassivate(SerializationGroupMemberContainer.java:51) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:189) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:46) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_17]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_17]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_17]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_17]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-29) An ear file with modules in subfolders can not deploy under AS 7.0
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-29?page=com.atlassian.jira.plugin.sy... ]
Jason Greene updated WFLY-29:
-----------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> An ear file with modules in subfolders can not deploy under AS 7.0
> ------------------------------------------------------------------
>
> Key: WFLY-29
> URL: https://issues.jboss.org/browse/WFLY-29
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Reporter: Adrian Zuo
> Assignee: David Lloyd
> Fix For: 8.0.0.CR1
>
> Attachments: migrate.ear, migrate.ear
>
>
> I have an ear file names migrate.ear which contains one ejb jar (ejb.jar) and one war file (war.war), if I put the ejb jar to a ejb folder and war file to war folder, the ear can not be depoyed.
> If I move the ejb jar and war file out, it can be deployed.
> Below structuer can be deployed:
> ejb.jar
> lib/
> lib/util-1.0-SNAPSHOT.jar
> lib/version.jar
> META-INF/
> META-INF/application.xml
> META-INF/MANIFEST.MF
> war.war
>
> Below structure can not be deployed:
> ejb/
> ejb/ejb.jar
> lib/
> lib/util-1.0-SNAPSHOT.jar
> lib/version.jar
> META-INF/
> META-INF/application.xml
> META-INF/MANIFEST.MF
> war/
> war/war.war
> Below is the error:
> http://community.jboss.org/message/630869#630869
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-19) JMX over remoting pollutes query results with ModelController objects
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-19?page=com.atlassian.jira.plugin.sy... ]
Jason Greene updated WFLY-19:
-----------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> JMX over remoting pollutes query results with ModelController objects
> ---------------------------------------------------------------------
>
> Key: WFLY-19
> URL: https://issues.jboss.org/browse/WFLY-19
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMX
> Reporter: NadirX
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query.
> This is a transcript of a chat we had about it on IRC:
> Oct 15 14:51:46 <ttarrant> darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected
> Oct 15 14:51:55 <ttarrant> darranl, i.e. ones that do not match the query
> Oct 15 14:52:09 <ttarrant> darranl, this is with 7.1.x
> Oct 15 14:52:57 <ttarrant> darranl, this works if I use the standard JMX over RMI
> Oct 15 14:53:08 --> fnasser (~fnasser(a)CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7
> Oct 15 14:53:09 <-- fnasser has quit (Changing host)
> Oct 15 14:53:09 --> fnasser (~fnasser@redhat/jboss/fnasser) has joined #jboss-as7
> Oct 15 14:53:09 --- ChanServ gives voice to fnasser
> Oct 15 14:53:16 <ttarrant> darranl, do you just pass the query the the mbeanserver ?
> Oct 15 14:53:39 <darranl> ttarrant: what kind of objects? within AS7 I think there are two things that could affec
> t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX
> Oct 15 14:53:54 <darranl> For #1 yes we just pass it to the MBEanServer and return whatever it returns
> Oct 15 14:54:04 <darranl> if it was a Remoting JMX bug maybe we are messing up the query
> Oct 15 14:54:16 <ttarrant> darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=*
> Oct 15 14:54:16 <darranl> But not sure if #2 could be the reason more is getting added
> Oct 15 14:54:32 <ttarrant> darranl, wait a sec
> Oct 15 14:54:57 <darranl> ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i
> s a remoting jmx issue or pass over if it is a domain management integration issue
> Oct 15 14:55:20 <darranl> regardless of where it is happenign it sounds like you may have discovered a bug
> Oct 15 14:56:23 <ttarrant> darranl, let me get the objects it's returning
> Oct 15 14:56:39 <darranl> ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m
> anagement integration
> Oct 15 14:56:42 <darranl> ok
> Oct 15 15:26:08 <ttarrant> darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem)
> Oct 15 15:51:24 <darranl> ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results
> Oct 15 15:51:53 <darranl> ttarrant: going RMI was just bypassing that as well
> Oct 15 15:52:05 <ttarrant> darranl, shall I open a Jira ?
> Oct 15 15:52:34 <ttarrant> darranl, I work around the issue by manually filtering the returned objects based on class name
> Oct 15 15:53:23 <darranl> ttarrant: it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months