September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-127) Use InMemory ApacheDS partitions when running tests with embedded LDAP

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-127?page=com.atlassian.jira.plugin... ] Josef Cacek moved WFLY-3899 to WFCORE-127: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-127 (was: WFLY-3899) > Use InMemory ApacheDS partitions when running tests with embedded LDAP > ---------------------------------------------------------------------- > > Key: WFCORE-127 > URL: https://issues.jboss.org/browse/WFCORE-127 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Josef Cacek > Assignee: Josef Cacek > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3898) Use InMemory ApacheDS partitions when running tests with embedded LDAP

by Josef Cacek (JIRA)

Josef Cacek created WFLY-3898: --------------------------------- Summary: Use InMemory ApacheDS partitions when running tests with embedded LDAP Key: WFLY-3898 URL: https://issues.jboss.org/browse/WFLY-3898 Project: WildFly Issue Type: Enhancement Reporter: Josef Cacek Assignee: Josef Cacek -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3899) Use InMemory ApacheDS partitions when running tests with embedded LDAP

by Josef Cacek (JIRA)

Josef Cacek created WFLY-3899: --------------------------------- Summary: Use InMemory ApacheDS partitions when running tests with embedded LDAP Key: WFLY-3899 URL: https://issues.jboss.org/browse/WFLY-3899 Project: WildFly Issue Type: Enhancement Reporter: Josef Cacek Assignee: Josef Cacek -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[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: -------------------------------- I could use reflection, but that's not nice: {code:java} DatagramSocket sock=new DatagramSocket(7500); Method getImpl=sock.getClass().getDeclaredMethod("getImpl"); getImpl.setAccessible(true); DatagramSocketImpl impl=(DatagramSocketImpl)getImpl.invoke(sock); System.out.println("impl = " + impl); Method setTimeToLive=impl.getClass().getDeclaredMethod("setTimeToLive", int.class); Method getTimeToLive=impl.getClass().getDeclaredMethod("getTimeToLive"); getTimeToLive.setAccessible(true); setTimeToLive.setAccessible(true); int ttl=0; ttl=(int)getTimeToLive.invoke(impl); System.out.println("ttl = " + ttl); ttl=5; setTimeToLive.invoke(impl, ttl); ttl=(int)getTimeToLive.invoke(impl); System.out.println("ttl = " + ttl); byte[] buf={'B', 'e', 'l', 'a'}; DatagramPacket packet=new DatagramPacket(buf, 0, buf.length, InetAddress.getByName("228.8.8.8"), 7500); sock.send(packet); {code} > 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 > 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)

10 years

1
0
0 / 0

[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/25/14 8:36 AM: --------------------------------------------------------- I found out that the DatagramSocket returned via {{DatagramChannel.socket()}} has a stupid readLock / writeLock held when calling {{receive()}} or {{send()}} respectively. This means that the unicast receiver in TP will block until unicast messages are received, but this will also keep the _sender_ from sending any data ! Very stupid and breaking the semantics of {{DatagramSocket.send()}} which allows for concurrent receiving and sending as there's no readLock or writeLock, but synchronization is done on the DatagramPacket only. I don't really want to use 2 separate unicast sockets now; one for receiving unicasts and one for sending unicasts. More investigation needed... was (Author: belaban): I found out that the DatagramSocket returned via {{DatagramChannel.socket()}} has a stupid readLock / writeLock held when calling {{receive()}} or {{send()}} respectively. This means that the unicast receiver in TP will block until unicast messages are received, but this will also keep the _sender_ from sending any data ! Very stupid and breaking the semantics of {{DatagramSocket.send()}} which allows for concurrent receiving and sending as there's no readLock or writeLock, but synchronization is done on the DatagramPacket only. I don't really want to use 2 separate unicast sockets now; one for receiving unicasts and one for sending unicasts. More investigate needed... > 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 > 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)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3357) Upgrade to JBoss NEgotiation 2.3.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3357?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3357: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1097859|https://bugzilla.redhat.com/show_bug.cgi?id=1097859] from MODIFIED to ON_QA > Upgrade to JBoss NEgotiation 2.3.1.Final > ---------------------------------------- > > Key: WFLY-3357 > URL: https://issues.jboss.org/browse/WFLY-3357 > Project: WildFly > Issue Type: Component Upgrade > Components: Server > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (REMJMX-88) Release Remoting JMX 1.1.3.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/REMJMX-88?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on REMJMX-88: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1113251|https://bugzilla.redhat.com/show_bug.cgi?id=1113251] from NEW to ASSIGNED > Release Remoting JMX 1.1.3.Final > -------------------------------- > > Key: REMJMX-88 > URL: https://issues.jboss.org/browse/REMJMX-88 > Project: Remoting JMX > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.3.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (REMJMX-86) RemotingConnector & VersionedConectionFactory need configurable connection, channel & versioned connection timeouts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/REMJMX-86?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on REMJMX-86: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1113247|https://bugzilla.redhat.com/show_bug.cgi?id=1113247] from POST to MODIFIED > RemotingConnector & VersionedConectionFactory need configurable connection, channel & versioned connection timeouts > -------------------------------------------------------------------------------------------------------------------- > > Key: REMJMX-86 > URL: https://issues.jboss.org/browse/REMJMX-86 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 2.0.0.Final > Reporter: Mustafa Musaji > Assignee: Brad Maxwell > Fix For: 1.1.3.Final, 2.0.1.CR1 > > > In [1] we have the following snippet of code which has a hardcoded value of 5 seconds. > {code:title=RemotingConnector.java} > // Now open the channel > final IoFuture<Channel> futureChannel = connection.openChannel(serviceName, OptionMap.EMPTY); > IoFuture.Status result = futureChannel.await(5, TimeUnit.SECONDS); > if (result == IoFuture.Status.DONE) { > channel = futureChannel.get(); > } else if (result == IoFuture.Status.FAILED) { > throw new IOException(futureChannel.getException()); > } else { > throw new RuntimeException("Operation failed with status " + result); > } > {code} > This should be a system property or the default value should be raised. > [1] https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jbo... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3891) Update appropriate web folders with newly changed schema

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-3891?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on WFLY-3891: ------------------------------------------- that is versioning the schemalocation content - but not the namespace/versions, right? Thus if that is what happens then we can't be suggesting to remove schemalocations in the quickstarts/xsd's can we ? since otherwise it is not versioned. > Update appropriate web folders with newly changed schema > -------------------------------------------------------- > > Key: WFLY-3891 > URL: https://issues.jboss.org/browse/WFLY-3891 > Project: WildFly > Issue Type: Task > Reporter: Rob Stryker > Assignee: Jason Greene > > Recent changes to several ejb3 xsd files require the following web folders to be updated with the most up-to-date schema files: > http://www.jboss.org/j2ee/schema/ > http://www.jboss.org/schema/jbossas/ > While this specific request comes due to WFLY-3189, it is related to WFLY-3434 about finding somewhere to host all schema. But something tells me putting them all on wildfly.org is not sufficient. Tools like eclipse will see the namespace and schemaLocation in our examples online (Such as https://docs.jboss.org/author/display/AS71/jboss-ejb3.xml+Reference) and copy-paste them verbatim. Those example files include things like the following: > {code} > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" > {code} > The important thing to note here is that it specifically points to http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd and so that specific schema file needs to be updated at THAT url, not at the wildfly URL. Tools like eclipse or other validators will try to fetch those specific urls. > If we intend to move all schemas to wildfly.org, then we probably need to update all examples to point to the new files as well. > At this point, the schemas I care most about are those mentioned in the following two PRs: > https://github.com/wildfly/wildfly/pull/6739 > https://github.com/jboss/metadata/pull/72 > But obviously all appropriate or changed xsd's should be updated on the web urls if possible. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[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: -------------------------------- I found out that the DatagramSocket returned via {{DatagramChannel.socket()}} has a stupid readLock / writeLock held when calling {{receive()}} or {{send()}} respectively. This means that the unicast receiver in TP will block until unicast messages are received, but this will also keep the _sender_ from sending any data ! Very stupid and breaking the semantics of {{DatagramSocket.send()}} which allows for concurrent receiving and sending as there's no readLock or writeLock, but synchronization is done on the DatagramPacket only. I don't really want to use 2 separate unicast sockets now; one for receiving unicasts and one for sending unicasts. More investigate needed... > 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 > 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)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014