[JBoss JIRA] (WFLY-3364) There is no way to change "task-core-threads"
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3364?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3364.
-------------------------------
Resolution: Out of Date
> There is no way to change "task-core-threads"
> ---------------------------------------------
>
> Key: WFLY-3364
> URL: https://issues.jboss.org/browse/WFLY-3364
> Project: WildFly
> Issue Type: Bug
> Components: IO
> Affects Versions: 8.1.0.CR1
> Environment: Ubuntu 14.04
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Reporter: Jay Xu
> Assignee: Tomaz Cerar
>
> I tried to change the value of "task-core-threads" in web admin console to 128, but after restart it is set back to the default value 2. I searched in standalone.xml and didn't found any "128" in it.
> Then I guessed and tried to add an attribute "task-core-threads" in the work config xml but that made wildfly fail to start with an error like "worker node doesn't have attribute task-core-threads":
> {code:xml}
> <worker name="default" io-threads="8" task-max-threads="512" task-core-threads="128"/>
> {code}
> So, "task-core-threads" is just a fake? My app server now meets a performance bottleneck for http connections, how to change task-core-threads's value?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (WFLY-67) method-params containing an array not correctly processed for EJB2.1 with CMT
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-67?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration updated WFLY-67:
----------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1180565, https://bugzilla.redhat.com/show_bug.cgi?id=1180571 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1180565)
> method-params containing an array not correctly processed for EJB2.1 with CMT
> -----------------------------------------------------------------------------
>
> Key: WFLY-67
> URL: https://issues.jboss.org/browse/WFLY-67
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: JBoss 7.2.0-Final Prerelease (Commit 4ed76c) and JBoss 7.1.3.Final on Win7/64 JDK 1.7.0_09
> Reporter: Robert Panzer
> Assignee: Ondrej Zizka
> Fix For: 8.0.0.Alpha1
>
> Attachments: cmt-never-array-params.zip
>
>
> It seems that the method-params for container transactions are not matched correctly if the contain arrays.
> I've got an EJB "First" that calls another EJB "Second". Both have the same interface containing a method void test(String[]);
> If I define the transaction attribute NEVER including method-params for "First" and without params for "Second" the test fails with
> JBAS014163: Transaction present on server in Never call (EJB3 13.6.2.6)
> I define the container transaction like this:
> <container-transaction>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String[]</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>int</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>Second</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> </method>
> <trans-attribute>Never</trans-attribute>
> </container-transaction>
> I will attach a test case that fails at the call to test(String[]) but successfully call test(String) and test(int).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (WFLY-3976) Memory leak in Websocket implementation (8.1.0 Final)
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3976?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3976:
------------------------------
Fix Version/s: 8.2.0.Final
> Memory leak in Websocket implementation (8.1.0 Final)
> -----------------------------------------------------
>
> Key: WFLY-3976
> URL: https://issues.jboss.org/browse/WFLY-3976
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Environment: CentOS 7
> Java 1.7.0_65-b17
> Reporter: Veli Cris
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 8.2.0.Final
>
>
> Creating 100k persistent websockets connections, exchanging small strings (with RemoteEndpoint.Basic) and finally disconnecting all connections the memory grows with ~1GB for each 100k. Basically the test is the following: the clients are connecting and sending a hello message to the server; the server is responding with a welcome string and the clients are disconnecting.
> The settings in onOpen() callback are:
> session.setMaxBinaryMessageBufferSize(10240);
> session.setMaxTextMessageBufferSize(10240);
> session.setMaxIdleTimeout(120000);
> session.getUserProperties().put("ts", System.currentTimeMillis());
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (WFLY-67) method-params containing an array not correctly processed for EJB2.1 with CMT
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-67?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration updated WFLY-67:
----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1180565
> method-params containing an array not correctly processed for EJB2.1 with CMT
> -----------------------------------------------------------------------------
>
> Key: WFLY-67
> URL: https://issues.jboss.org/browse/WFLY-67
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: JBoss 7.2.0-Final Prerelease (Commit 4ed76c) and JBoss 7.1.3.Final on Win7/64 JDK 1.7.0_09
> Reporter: Robert Panzer
> Assignee: Ondrej Zizka
> Fix For: 8.0.0.Alpha1
>
> Attachments: cmt-never-array-params.zip
>
>
> It seems that the method-params for container transactions are not matched correctly if the contain arrays.
> I've got an EJB "First" that calls another EJB "Second". Both have the same interface containing a method void test(String[]);
> If I define the transaction attribute NEVER including method-params for "First" and without params for "Second" the test fails with
> JBAS014163: Transaction present on server in Never call (EJB3 13.6.2.6)
> I define the container transaction like this:
> <container-transaction>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String[]</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>int</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>Second</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> </method>
> <trans-attribute>Never</trans-attribute>
> </container-transaction>
> I will attach a test case that fails at the call to test(String[]) but successfully call test(String) and test(int).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (WFLY-2627) EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2627?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2627:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1180556
> EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-2627
> URL: https://issues.jboss.org/browse/WFLY-2627
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Environment: jdk1.7.0_45_x64, Windows 7
> Reporter: Norbert Bumm
> Assignee: David Lloyd
> Attachments: arquillian-jpa.zip, wildfly-src-7.2.0.Final-TransactionBug.patch
>
>
> If there is a global transaction declaration for “Supports” and a “Required” declaration for a specific Method the “Required” gets ignored. I first encountered the problem with an old 2.1 EJB, but the problem is also there with a 3.1 EJB with deployment descriptor. It works correct with annotations.
> ejb-jar.xml snippet
> {code:xml}
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Supports</trans-attribute>
> </container-transaction>
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>createUser</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (WFLY-1751) org.jboss.as.test.integration.jaxrs.provider.CustomProvidersTestCase.testProvidersInTwoWars if not skipped would fail on HP UX due to locale dependency
by Pavel Jelinek (JIRA)
[ https://issues.jboss.org/browse/WFLY-1751?page=com.atlassian.jira.plugin.... ]
Pavel Jelinek resolved WFLY-1751.
---------------------------------
Resolution: Done
It was merged long time ago.
> org.jboss.as.test.integration.jaxrs.provider.CustomProvidersTestCase.testProvidersInTwoWars if not skipped would fail on HP UX due to locale dependency
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1751
> URL: https://issues.jboss.org/browse/WFLY-1751
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Environment: HP UX 11 v3
> Reporter: Pavel Jelinek
> Assignee: Pavel Jelinek
> Priority: Minor
>
> Running on HP UX the test fails with stacktrace:
> org.junit.ComparisonFailure: expected:<[$]> but was:<[USD]>
> at org.junit.Assert.assertEquals(Assert.java:115)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.test.integration.jaxrs.provider.CustomProvidersTestCase.testProvidersInTwoWars(CustomProvidersTestCase.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> 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)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> 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$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (JBMETA-383) Create test to guard against schema and dtd changes
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/JBMETA-383?page=com.atlassian.jira.plugin... ]
Carlo de Wolf updated JBMETA-383:
---------------------------------
Description:
{quote}
On 01/09/2015 09:55 AM, Max Rydahl Andersen wrote:
Now what is important for EAP and WF team to realize is that they must ensure these schemas stays the same and compatible with both...and if something need to divert it needs to get a different versioned name (which I honestly hope will never happen)
{quote}
was:
{quote=On 01/09/2015 09:55 AM, Max Rydahl Andersen wrote:}
> Now what is important for EAP and WF team to realize is that they must ensure these schemas stays the same and compatible with both...and if something need to divert it needs to get a different versioned name (which I honestly hope will never happen)
{quote}
> Create test to guard against schema and dtd changes
> ---------------------------------------------------
>
> Key: JBMETA-383
> URL: https://issues.jboss.org/browse/JBMETA-383
> Project: JBoss Metadata
> Issue Type: Task
> Reporter: Carlo de Wolf
> Assignee: Carlo de Wolf
>
> {quote}
> On 01/09/2015 09:55 AM, Max Rydahl Andersen wrote:
> Now what is important for EAP and WF team to realize is that they must ensure these schemas stays the same and compatible with both...and if something need to divert it needs to get a different versioned name (which I honestly hope will never happen)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months