[JBoss JIRA] (JGRP-1880) UDP.ip_ttl is ignored and is always 1
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1880?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1880 at 9/4/14 4:11 AM:
--------------------------------------------------------
Class {{DatagramChannel}} has the ability to set {{IP_MULICAST_TTL}} as an option. Investigate whether we can use a {{DatagramChannel}} instead of a {{DatagramSocket}}. Perhaps we can create a {{DatagramChannel}}, but then call {{DatagramChannel.socket()}} to simply use the underlying {{DatagramSocket}} instead.
Example:
{code}
DatagramChannel ch=DatagramChannel.open();
ch.setOption(StandardSocketOptions.IP_MULICAST_TTL, 8); // sets TTL to 8
DatagramSocket sock=ch.socket()
// use sock
{code}
was (Author: belaban):
Class {{DatagramChannel}} has the ability to set {{IP_MULICAST_TTL}} as an option. Investigate whether we can use a {{DatagramChannel}} instead of a {{DatagramSocket}}. Perhaps we can create a {{DatagramChannel}}, but then call {{DatagramChannel.socket()}} to simply use the underlying {{DatagramSocket}} instead.
> UDP.ip_ttl is ignored and is always 1
> -------------------------------------
>
> Key: JGRP-1880
> URL: https://issues.jboss.org/browse/JGRP-1880
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> Since we switched from using a {{MulticastSocket}} for sending of multicast packets to a {{DatagramSocket}}, the time-to-live (TTL) of a packet is always {{1}}. The reason is that method {{setTimeToLive()}} only exists in {{MulticastSocket}}, but not in {{DatagramSocket}}.
> We cannot revert the code and use a {{MulticastSocket}} to send multicasts, as this won't reveal the real IP address of the sender, but only the multicast address, and the real address is needed to drop packets at the _transport level_.
> Investigate whether we could use reflection to get the {{DatagramSocketImpl}} and call {{setTimeToLive()}}.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1880) UDP.ip_ttl is ignored and is always 1
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1880?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1880:
--------------------------------
Class {{DatagramChannel}} has the ability to set {{IP_MULICAST_TTL}} as an option. Investigate whether we can use a {{DatagramChannel}} instead of a {{DatagramSocket}}. Perhaps we can create a {{DatagramChannel}}, but then call {{DatagramChannel.socket()}} to simply use the underlying {{DatagramSocket}} instead.
> UDP.ip_ttl is ignored and is always 1
> -------------------------------------
>
> Key: JGRP-1880
> URL: https://issues.jboss.org/browse/JGRP-1880
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> Since we switched from using a {{MulticastSocket}} for sending of multicast packets to a {{DatagramSocket}}, the time-to-live (TTL) of a packet is always {{1}}. The reason is that method {{setTimeToLive()}} only exists in {{MulticastSocket}}, but not in {{DatagramSocket}}.
> We cannot revert the code and use a {{MulticastSocket}} to send multicasts, as this won't reveal the real IP address of the sender, but only the multicast address, and the real address is needed to drop packets at the _transport level_.
> Investigate whether we could use reflection to get the {{DatagramSocketImpl}} and call {{setTimeToLive()}}.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1880) UDP.ip_ttl is ignored and is always 1
by Bela Ban (JIRA)
Bela Ban created JGRP-1880:
------------------------------
Summary: UDP.ip_ttl is ignored and is always 1
Key: JGRP-1880
URL: https://issues.jboss.org/browse/JGRP-1880
Project: JGroups
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6
Since we switched from using a {{MulticastSocket}} for sending of multicast packets to a {{DatagramSocket}}, the time-to-live (TTL) of a packet is always {{1}}. The reason is that method {{setTimeToLive()}} only exists in {{MulticastSocket}}, but not in {{DatagramSocket}}.
We cannot revert the code and use a {{MulticastSocket}} to send multicasts, as this won't reveal the real IP address of the sender, but only the multicast address, and the real address is needed to drop packets at the _transport level_.
Investigate whether we could use reflection to get the {{DatagramSocketImpl}} and call {{setTimeToLive()}}.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFLY-3808) PartitionPlan.getThreads() returning zero value causes batch job not be started
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-3808?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez reassigned WFLY-3808:
-----------------------------------------------
Assignee: Enrique González Martínez (was: Jason Greene)
> PartitionPlan.getThreads() returning zero value causes batch job not be started
> -------------------------------------------------------------------------------
>
> Key: WFLY-3808
> URL: https://issues.jboss.org/browse/WFLY-3808
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final
> Reporter: Ari Silvan
> Assignee: Enrique González Martínez
>
> If you define a batch job to be divided to multiple partitions and write a PartitionMapper returning a PartitionPlanImpl object but don't override getThreads method, which means getThreads returns zero meaning thread count should be equal to partition count, but the batch job doesn't start.
> See http://docs.oracle.com/javaee/7/api/javax/batch/api/partition/PartitionPl...
> In GlassFish this works as expected: if getThreads is not overridden (thus returning zero), batch job is started in as many threads as there are partitions.
> See steps to reproduce for further details.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1878:
--------------------------------
Hmm, I tried this with JDK 7 and it worked... I'll write a simple test that shows the issue, which we can submit to Oracle if this turns out to be a JDK bug.
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.2.14, 3.6
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1878:
--------------------------------
I'm not aware that we've ever supported binding to loopback ({{127.0.0.x}}) and routable ({{192.168.x.x}}) addresses.
Note that binding to different _routable_ addresses (e.g. {{192.168.1.10}} and {{192.168.1.11}}) works.
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.2.14, 3.6
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFLY-2344) undertow claims already registered
by Venkata Rammohan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.... ]
Venkata Rammohan commented on WFLY-2344:
----------------------------------------
I think, the problem is with this line : <location name="/" handler="welcome-content">
You are registering the same location for more than one host.
I got the same problem and could resolve it by removing that line (name="/" could be anything , but it should be unique for host location.)
> undertow claims already registered
> ----------------------------------
>
> Key: WFLY-2344
> URL: https://issues.jboss.org/browse/WFLY-2344
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: miguel deanda
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> <buffer-caches>
> <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> </buffer-caches>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> </host>
> <host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> <location name="/" handler="welcome-content">
> <filter-ref name="connection-limit"/>
> </location>
> </host>
> </server>
> <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> <jsp-config/>
> <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> </handlers>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFLY-1402) Too Many Dependencies
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1402?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1402:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1136956, https://bugzilla.redhat.com/show_bug.cgi?id=1138111 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1136956)
> Too Many Dependencies
> ---------------------
>
> Key: WFLY-1402
> URL: https://issues.jboss.org/browse/WFLY-1402
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha1
> Environment: W7 64 bit
> Reporter: Michael McGovern
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> Large app ~ 1000 SLSB gets
> Caused by: java.lang.IllegalArgumentException: Too many dependencies specified (max is 16383)
> at org.jboss.msc.service.ServiceBuilderImpl.doAddDependency(ServiceBuilderImpl.java:216) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceBuilderImpl.addDependenciesNoCheck(ServiceBuilderImpl.java:158) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceBuilderImpl.addDependencies(ServiceBuilderImpl.java:152) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceBuilderImpl.addDependencies(ServiceBuilderImpl.java:142) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.as.naming.deployment.JndiNamingDependencyProcessor.deploy(JndiNamingDependencyProcessor.java:59)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha1.jar:8.0.0.Alpha1]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1879) log4j 2 suport error
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1879?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1879:
---------------------------
Fix Version/s: 3.6
> log4j 2 suport error
> ---------------------
>
> Key: JGRP-1879
> URL: https://issues.jboss.org/browse/JGRP-1879
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.4, 3.5
> Environment: jdk 7
> Reporter: ming yue
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> LogFactory suport jdk log,log4j,log4j 2,but useing code like this:
> USE_JDK_LOGGER=isPropertySet(Global.USE_JDK_LOGGER);
> IS_LOG4J_AVAILABLE=isAvailable("org.apache.log4j.Logger");
> IS_LOG4J2_AVAILABLE=isAvailable("org.apache.logging.log4j.core.Logger");
> initialize var flag,
> the isAvailable function depend on ClassNotFoundException ,when useing log4j 2 Log4j 1.x bridge, has org.apache.log4j.Logger class ,then exception is not ClassNotFoundException ,change isAvailable cunction to:
> protected static boolean isAvailable(String classname) {
> try {
> return Class.forName(classname) != null;
> }
> catch(Exception cnfe) {
> return false;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1878:
---------------------------
Fix Version/s: 3.6
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.2.14, 3.6
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months