[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1799:
-------------------------------------------
One reason why the test is failing is that with ever larger values, the RPC call times out:
{noformat}
testing with 10000 bytes
test took: 23 ms
rsps:
10000 bytes from B
10000 bytes from A
10000 bytes from C
testing with 20000 bytes
test took: 30 ms
rsps:
20000 bytes from B
20000 bytes from A
20000 bytes from C
testing with 40000 bytes
test took: 31 ms
rsps:
40000 bytes from B
40000 bytes from A
40000 bytes from C
testing with 80000 bytes
test took: 33 ms
rsps:
80000 bytes from B
80000 bytes from A
80000 bytes from C
testing with 100000 bytes
test took: 804 ms
rsps:
100000 bytes from B
100000 bytes from A
100000 bytes from C
testing with 200000 bytes
test took: 1001 ms
rsps:
200000 bytes from B
200000 bytes from A
200000 bytes from C
testing with 400000 bytes
test took: 1001 ms
rsps:
400000 bytes from B
400000 bytes from A
400000 bytes from C
testing with 800000 bytes
test took: 1793 ms
rsps:
800000 bytes from B
800000 bytes from A
800000 bytes from C
testing with 1000000 bytes
test took: 67 ms
rsps:
1000000 bytes from B
1000000 bytes from A
1000000 bytes from C
testing with 2000000 bytes
test took: 1944 ms
rsps:
2000000 bytes from B
2000000 bytes from A
2000000 bytes from C
testing with 5000000 bytes
test took: 1247 ms
rsps:
5000000 bytes from B
5000000 bytes from A
5000000 bytes from C
testing with 10000000 bytes
test took: 7970 ms
rsps:
10000000 bytes from B
10000000 bytes from A
10000000 bytes from C
testing with 20000000 bytes
test took: 12262 ms
rsps:
20000000 bytes from B
20000000 bytes from A
20000000 bytes from C
testing with 50000000 bytes
test took: 20001 ms
rsps:
50000000 bytes from B
50000000 bytes from A
java.lang.AssertionError
at org.jgroups.blocks.RpcDispatcherTest._testLargeValue(RpcDispatcherTest.java:548)
at org.jgroups.blocks.RpcDispatcherTest.testLargeReturnValue(RpcDispatcherTest.java:443)
{noformat}
I can quite easily reproduce this on my machine. The RPC call times out partway through processing and leaves an incomplete result. When I extend the timeout from 20 seconds to 30 seconds, the test passes.
We can probably eliminate these errors by extending the timeout from 20 seconds to 30 seconds to take account of slow machines.
I have also added in count of how many ms each RPC call takes, which helps to see why it may have failed (i.e. tool too long).
Bela, is extending the timeout something you would consider?
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.... ]
James Perkins edited comment on WFLY-2959 at 3/5/14 4:35 PM:
-------------------------------------------------------------
I got this to work with 2.2.3. I noticed that for some reason {{com.fasterxml.jackson.datatype:jackson-datatype-hibernate4:2.2.3}} has a dependency on 2.3.x versions of {{com.fasterxml.jackson.core:jackson-core}} and {{com.fasterxml.jackson.core:jackson-databind}}.
I changed the version in the POM and added some exclusions and new dependencies and it worked.
{code:xml}
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-hibernate4</artifactId>
<version>2.2.3</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</exclusion>
</exclusions>
</dependency>
{code}
The result was
{code}
[
{
personId: "df53104a-d5fa-42ff-a15d-d69900e27dfa",
personFirstName: "Bob",
personLastName: "Bob",
personAddresses: null
}
]
{code}
was (Author: jamezp):
I got this to work with 2.2.3. I noticed that for some reason {{com.fasterxml.jackson.datatype:jackson-datatype-hibernate4:2.2.3}} has a dependency on 2.3.x versions of {{com.fasterxml.jackson.core:jackson-core}} and {{com.fasterxml.jackson.core:jackson-databind}}.
I changed the version in the POM and added some exclusions and new dependencies and it worked.
{code:xml}
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-hibernate4</artifactId>
<version>2.2.3</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</exclusion>
</exclusions>
</dependency>
{code}
> Downgrade Jackson dependency
> ----------------------------
>
> Key: WFLY-2959
> URL: https://issues.jboss.org/browse/WFLY-2959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.Final
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.1.Final
>
> Attachments: org.jboss.test.test-jackson.tar.gz, org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64...] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-2959) Downgrade Jackson dependency
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2959?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-2959:
-------------------------------------
I got this to work with 2.2.3. I noticed that for some reason {{com.fasterxml.jackson.datatype:jackson-datatype-hibernate4:2.2.3}} has a dependency on 2.3.x versions of {{com.fasterxml.jackson.core:jackson-core}} and {{com.fasterxml.jackson.core:jackson-databind}}.
I changed the version in the POM and added some exclusions and new dependencies and it worked.
{code:xml}
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-hibernate4</artifactId>
<version>2.2.3</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</exclusion>
</exclusions>
</dependency>
{code}
> Downgrade Jackson dependency
> ----------------------------
>
> Key: WFLY-2959
> URL: https://issues.jboss.org/browse/WFLY-2959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.Final
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.1.Final
>
> Attachments: org.jboss.test.test-jackson.tar.gz, org.jboss.test.test-jackson.tar.gz
>
>
> Jackson was upgraded to 2.3.0 which contains a [bug|https://github.com/FasterXML/jackson-jaxrs-providers/commit/bafb6fb64...] that breaks RESTEasy. RESTEasy currently uses 2.2.1. Downgrading to at least 2.2.3, which is what CR1 is at, seems to resolve this issue.
> We should likely keep the version aligned with RESTEasy, but since CR1 was using 2.2.3 with no issues, I think reverting back to that should be fine.
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-2969) WildFly 8/Undertow 1 handles URL fragments differently than JBoss EAP 6.2/Apache-Coyote/1.1
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2969?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2969.
----------------------------------
Fix Version/s: 8.0.1.Final
Resolution: Done
> WildFly 8/Undertow 1 handles URL fragments differently than JBoss EAP 6.2/Apache-Coyote/1.1
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-2969
> URL: https://issues.jboss.org/browse/WFLY-2969
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Michal Babacek
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 8.0.1.Final
>
>
> I have a bunch of URL tests, executed against EAP 6.2.0 directly and then proxied through mod_cluster 1.2.6. These all pass.
> I tried to run the same with {{Wildfly-8.0.1.Final-SNAPSHOT, HEAD:be3a13e6}} with a surprising result of seeing some differences in how are various Request attributes reported from within the servlet:
> Here we go,{{8080}} is where either EAP or WFLY listens:
> || ||{{curl 'http://10.16.88.19:8080/clusterbench/requestinfo//?;?=44&test=OK;devil=3&...'}}||
> |EAP|Parameters map: {test=OK;devil=3, 777=666, ;?=44}|
> |WFY|Parameters map: {=, 777=666, test=OK;devil=3, ;?=44}|
> *Note:* {{Parameters map: \{key=value, key=value, ..., ...\}}}, so there is like an empty key and and empty value for WFLY....
> This is the [CommonRequestInfoServlet.java|https://github.com/Karm/clusterbench/blob/s...] that produced the output.
> {code}
> Map params = request.getParameterMap();
> Iterator i = params.keySet().iterator();
> while (i.hasNext()) {
> String key = (String) i.next();
> String value = ((String[]) params.get(key))[0];
> responseText.append(key);
> responseText.append("=");
> responseText.append(value);
> if (i.hasNext()) responseText.append(", ");
> }
> {code}
> It is, indeed, possible that these mangled URLs are slipping through the cracks of [RFC|http://tools.ietf.org/html/rfc3986] and should be either "fixed" or URL encoded, yet I find the different interpretations disturbing.
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-3074) Hibernate 3.x static module cannot be used
by Scott Marlow (JIRA)
Scott Marlow created WFLY-3074:
----------------------------------
Summary: Hibernate 3.x static module cannot be used
Key: WFLY-3074
URL: https://issues.jboss.org/browse/WFLY-3074
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JPA / Hibernate
Affects Versions: 8.0.0.Final
Reporter: Scott Marlow
Assignee: Scott Marlow
Fix For: 8.0.1.Final
See forum reference for details. Workaround is to bundle Hibernate 3 jars with application.
--
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
12 years, 2 months
[JBoss JIRA] (JBWEB-291) Add org.apache.catalina.connector.Request.asyncTimeout parameter
by Ron Sigal (JIRA)
Ron Sigal created JBWEB-291:
-------------------------------
Summary: Add org.apache.catalina.connector.Request.asyncTimeout parameter
Key: JBWEB-291
URL: https://issues.jboss.org/browse/JBWEB-291
Project: JBoss Web
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Ron Sigal
Assignee: Remy Maucherat
Priority: Minor
Resteasy has a @Suspend parameter that gives an asynchronous timeout value when it has a parameter, e.g., @Suspend(10000). If it has no parameter, then the default asynchronous timeout of the container is used. For example, Jetty 8 has a default value of 30000. But JBoss Web has a default value of -1, so that an asynchronous request never times out.
I've set the priority of this issue to Minor, since it affects only one of our test cases. Someone else might need it for a real application, though.
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-3067) Annotations from .ear/lib are not visible to DUPs when processing subdeployments
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3067:
--------------------------------------
This should be fixed by changing the webservices subsystem to use EEModuleClassDescription.
> Annotations from .ear/lib are not visible to DUPs when processing subdeployments
> --------------------------------------------------------------------------------
>
> Key: WFLY-3067
> URL: https://issues.jboss.org/browse/WFLY-3067
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Class Loading
> Affects Versions: 8.0.0.Final
> Reporter: Kyle Lape
> Assignee: David Lloyd
>
> Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {noformat}
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-3073) MBeanServer.createMBean methods that take a classloader don't work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3073:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1073106
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
> Key: WFLY-3073
> URL: https://issues.jboss.org/browse/WFLY-3073
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 8.0.0.Final
> Reporter: Stuart Douglas
> Assignee: Kabir Khan
> Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)
--
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
12 years, 2 months