[JBoss JIRA] (WFLY-2046) socketBuffer setting should be provided to allow fine tuning network communication.
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2046?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2046:
------------------------------
Component/s: Web (Undertow)
(was: Web (JBoss Web))
> socketBuffer setting should be provided to allow fine tuning network communication.
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2046
> URL: https://issues.jboss.org/browse/WFLY-2046
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Gourav Mukherjee
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.Final
>
>
> In JBoss 5.1, there used to be a setting called socketBuffer which we could configure in the server.xml inside jbossweb.sar i.e. jbossweb.sar\server.xml, it looked something like this.
> <Connector protocol="HTTP/1.1"
> port="8080"
> address="${jboss.bind.address}"
> connectionTimeout="20000"
> redirectPort="8443"
> socketBuffer="64000"/>
> It would be nice to get this setting back because tuning this improves HTTP transfer performance.
--
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-2046) socketBuffer setting should be provided to allow fine tuning network communication.
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2046?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-2046.
-------------------------------
Assignee: Tomaz Cerar (was: Remy Maucherat)
Fix Version/s: 8.0.0.Final
Resolution: Done
Undertow subsystem in WildFly 8 allows tuning buffers for listeners.
> socketBuffer setting should be provided to allow fine tuning network communication.
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2046
> URL: https://issues.jboss.org/browse/WFLY-2046
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Reporter: Gourav Mukherjee
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.Final
>
>
> In JBoss 5.1, there used to be a setting called socketBuffer which we could configure in the server.xml inside jbossweb.sar i.e. jbossweb.sar\server.xml, it looked something like this.
> <Connector protocol="HTTP/1.1"
> port="8080"
> address="${jboss.bind.address}"
> connectionTimeout="20000"
> redirectPort="8443"
> socketBuffer="64000"/>
> It would be nice to get this setting back because tuning this improves HTTP transfer performance.
--
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-2459) Serialization of java.time classes on EJB calls fails
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-2459?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-2459:
-----------------------------------
This should be resolved in WildFly 8.x with upgrades to JBoss Marshalling, which doesn't use *Creators anymore. Can you verify?
> Serialization of java.time classes on EJB calls fails
> -----------------------------------------------------
>
> Key: WFLY-2459
> URL: https://issues.jboss.org/browse/WFLY-2459
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Beta1
> Environment: JBoss AS 7.2
> Reporter: Steven Pessall
> Assignee: David Lloyd
> Labels: AS7, EJB3
>
> First of all: We stumbled on the issue desribed here on JBoss AS 7.2, but the relevant source coude seems to be unchanged in WildFly.
> In method org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation() a ClonerConfiguration object is programmatically created for the configuration of a org.jboss.marshalling.cloner.SerializingCloner instance.
> The default configuration causes IllegalAccessExceptions when serializing classes of the new java.time package (Java 8) respectively for the org.threeten library (Java 7 backport of JSR-310).
> Stacktrace:
> java.lang.RuntimeException: JBAS014154: Failed to marshal EJB parameters
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:270) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:259) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:170) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBHomeCreateInterceptor.handleInvocation(EJBHomeCreateInterceptor.java:79) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:177) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:161) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at com.sun.proxy.$Proxy124.getList(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at kam.cmd.boundary.access.MDListService$431771952$Proxy$_$$_Weld$Proxy$.getList(MDListService$431771952$Proxy$_$$_Weld$Proxy$.java) [cmd-core-boundary-0.0.10-SNAPSHOT.jar:]
> at kam.cmd.client.AbstractMasterDataClient.getData(AbstractMasterDataClient.java:57) [cmd-core-client-base-0.0.10-SNAPSHOT.jar:]
> at kam.cmd.client.ejb.EJBMasterDataClient$Proxy$_$$_WeldClientProxy.getData(EJBMasterDataClient$Proxy$_$$_WeldClientProxy.java) [cmd-core-client-ejb-0.0.10-SNAPSHOT.jar:]
> at kam.cmd.resourcebrowser.BackwareBrowser.getRes(BackwareBrowser.java:37) [classes:]
> at kam.cmd.resourcebrowser.BackwareBrowser$Proxy$_$$_WeldClientProxy.getRes(BackwareBrowser$Proxy$_$$_WeldClientProxy.java) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.5.Final.jar:]
> ... 19 more
> Caused by: java.io.InvalidClassException: org.threeten.bp.Ser; Illegal access exception occurred accessing the constructor: java.lang.IllegalAccessException: Class org.jboss.marshalling.reflect.PublicReflectiveCreator can not access a member of class org.threeten.bp.Ser with modifiers "public"
> at org.jboss.marshalling.reflect.PublicReflectiveCreator.create(PublicReflectiveCreator.java:43)
> at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:240)
> at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:174)
> at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:134)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:268) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> ... 57 more
> The cause of the problem is, that the default configuration of the SerializingCloner uses the class org.jboss.marshalling.reflect.PublicReflectiveCreator for the instantiation of the serialized classes, which tries to directly call the default constructor. While the class org.threeten.bp.Ser does have a public constructor, the class itself only has package visibility, causing the IllegalAccessException.
> There is another implementation org.jboss.marshalling.reflect.ReflectiveCreator, which actually forces the accessibility of the constructor to be true. If an instance of this class was configured as externalizedCreator in ClonerConfiguration, the problem would be solved. But currently there is no way to influence the ClonerConfiguration used by the class LocalEjbReceiver.
--
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-2641) ARQ upgrade likely to cause test failures
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-2641.
-------------------------------
Assignee: Tomaz Cerar (was: Jason Greene)
Fix Version/s: 8.0.0.Final
(was: 9.0.0.CR1)
Resolution: Partially Completed
We did manage to fix our problems by using one off release of arquillian core 1.1.2
> ARQ upgrade likely to cause test failures
> ------------------------------------------
>
> Key: WFLY-2641
> URL: https://issues.jboss.org/browse/WFLY-2641
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase) Time elapsed: 0.028 sec <<< ERROR!
> java.lang.NullPointerException: null
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> {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
12 years, 2 months
[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-1172:
------------------------------
Assignee: (was: Remy Maucherat)
> mechanism to load tag libraries from module
> -------------------------------------------
>
> Key: WFLY-1172
> URL: https://issues.jboss.org/browse/WFLY-1172
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Ivica Loncar
> Priority: Critical
> Labels: modules, tag, taglib, tld
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF.
> The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way.
> Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld.
--
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-1172) mechanism to load tag libraries from module
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-1172:
------------------------------
Component/s: Web (Undertow)
(was: Web (JBoss Web))
> mechanism to load tag libraries from module
> -------------------------------------------
>
> Key: WFLY-1172
> URL: https://issues.jboss.org/browse/WFLY-1172
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Ivica Loncar
> Assignee: Remy Maucherat
> Priority: Critical
> Labels: modules, tag, taglib, tld
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF.
> The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way.
> Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld.
--
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-1172) mechanism to load tag libraries from module
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-1172:
-----------------------------------
[~ilx], can you verify if this still occurs on WildFly 8?
> mechanism to load tag libraries from module
> -------------------------------------------
>
> Key: WFLY-1172
> URL: https://issues.jboss.org/browse/WFLY-1172
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Ivica Loncar
> Assignee: Remy Maucherat
> Priority: Critical
> Labels: modules, tag, taglib, tld
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF.
> The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way.
> Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld.
--
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