September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1149) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1149?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1149: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=923836 > Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1149 > URL: https://issues.jboss.org/browse/WFLY-1149 > Project: WildFly > Issue Type: Bug > Components: Naming, Test Suite > Environment: IBM JDK 6 (build 20110203_074623) > IBM JDK 7 (build 20120809_118929) > Reporter: Ivo Studensky > Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml > > > RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed. > test.log snippet: > {noformat} > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl@345642e1 > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl@1dc68cf2 > 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false} > 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447 > 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open > at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333) > at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105) > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83) > at javax.naming.InitialContext.lookup(InitialContext.java:422) > at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74) > {noformat} > server.log snippet: > {noformat} > 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar" > 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 > 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01 > 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed. > 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1886) CENTRAL_LOCK: provide option to make a node the lock owner instead of node:thread

by Bela Ban (JIRA)

Bela Ban created JGRP-1886: ------------------------------ Summary: CENTRAL_LOCK: provide option to make a node the lock owner instead of node:thread Key: JGRP-1886 URL: https://issues.jboss.org/browse/JGRP-1886 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6 When using distributed locks, we currently use {{Owner}} as identity that holds a lock. {{Owner}} consists of the node's address and the thread's ID. This has the same semantics as {{ReentrantLock}} which makes the thread which called {{Lock.lock()}} the owner. However, in some scenarios, this is too strong and some applications only want the current node to be the lock owner. This is needed in cases where thread T1 locks a lock but thread T2 needs to unlock it. This means, however, that all threads in a given node can lock or unlock the same lock. h4. Solution * Add property {{use_thread_id_for_lock_owner}} to {{CENTRAL_LOCK}} (default: false) * When set, {{getOwner()}} sets the thread-id to 0 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1851) RSVP: add option to not block caller

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1851?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1851. ---------------------------- Resolution: Done > RSVP: add option to not block caller > ------------------------------------ > > Key: JGRP-1851 > URL: https://issues.jboss.org/browse/JGRP-1851 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6 > > > In RSVP we have a {{resend_interval}} at which empty messages are sent to trigger retransmission and a {{timeout}} which is the max time a caller will block until all acks have been received. > In the {{down()}} method, the caller blocks until all acks have been received or a timeout occured. Then the resend task is stopped and the entry removed from the {{ids}} map. > In some cases, we may want to not block the caller, so that the calling thread returns immediately, but nevertheless perform resending until all acks have been received or the timeout occurred. This is a new property {{block}}. > An example of where this is useful is {{RpcDispatcher.callRemoteMethodsWithFuture()}}: here, we want the call to return immediately with a future, and then - later - potentially block on it. However, if we have the RSVP flag set, then sending the message will block in RSVP until all acks have been received. This breaks the semantics of {{callRemoteMethodsWithFuture()}}. > Another example is async RPCs (mode={{GET_NONE}}); here we'd block if RSVP is set even though we shouldn't. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3832) Upgrade JBMETA to 8.0.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3832?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3832: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1139626|https://bugzilla.redhat.com/show_bug.cgi?id=1139626] from NEW to ASSIGNED > Upgrade JBMETA to 8.0.1.Final > ----------------------------- > > Key: WFLY-3832 > URL: https://issues.jboss.org/browse/WFLY-3832 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Bartosz Baranowski > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-379) Missing param-name in a web.xml causes NullPointerException during deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-379?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBMETA-379: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1125421|https://bugzilla.redhat.com/show_bug.cgi?id=1125421] from ASSIGNED to POST > Missing param-name in a web.xml causes NullPointerException during deployment > ------------------------------------------------------------------------------ > > Key: JBMETA-379 > URL: https://issues.jboss.org/browse/JBMETA-379 > Project: JBoss Metadata > Issue Type: Bug > Components: web > Affects Versions: 8.0.0.Final > Reporter: Jay Kumar SenSharma > Assignee: Jean-Frederic Clere > Fix For: 8.0.1.Final > > Attachments: ContextParamNullDemo.war > > > - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following: > {code} > 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war") > 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: java.lang.NullPointerException > at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > ... 5 more > 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\" > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1851) RSVP: add option to not block caller

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1851?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1851: -------------------------------- Actually, this does work: in the resend task, we send a beacon for every destination _only once_. The receiver doesn't need to send a response, as this is only used to trigger potential retransmission. > RSVP: add option to not block caller > ------------------------------------ > > Key: JGRP-1851 > URL: https://issues.jboss.org/browse/JGRP-1851 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6 > > > In RSVP we have a {{resend_interval}} at which empty messages are sent to trigger retransmission and a {{timeout}} which is the max time a caller will block until all acks have been received. > In the {{down()}} method, the caller blocks until all acks have been received or a timeout occured. Then the resend task is stopped and the entry removed from the {{ids}} map. > In some cases, we may want to not block the caller, so that the calling thread returns immediately, but nevertheless perform resending until all acks have been received or the timeout occurred. This is a new property {{block}}. > An example of where this is useful is {{RpcDispatcher.callRemoteMethodsWithFuture()}}: here, we want the call to return immediately with a future, and then - later - potentially block on it. However, if we have the RSVP flag set, then sending the message will block in RSVP until all acks have been received. This breaks the semantics of {{callRemoteMethodsWithFuture()}}. > Another example is async RPCs (mode={{GET_NONE}}); here we'd block if RSVP is set even though we shouldn't. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-585) inconsistent behavior of & bitwise operator

by Rahul Singh (JIRA)

[ https://issues.jboss.org/browse/DROOLS-585?page=com.atlassian.jira.plugin... ] Rahul Singh commented on DROOLS-585: ------------------------------------ Hi Mario can you please let me know in which release this fix is going and when is the release planned. Thanks > inconsistent behavior of & bitwise operator > ------------------------------------------- > > Key: DROOLS-585 > URL: https://issues.jboss.org/browse/DROOLS-585 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final > Reporter: Rahul Singh > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.2.0.CR1 > > > inconsistent behavior of & bitwise operator > after writing a rule given below > no-loop > when > f: Person( > ((101 & age) != 0) > ) > then > f.setFound(true); > end > after calling this several times say 100 it gives inconsistent result. Similar behavior is observed if we place bitwise '&' with bitwise '|' -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-46) Fix intermittent failures in DeploymentOverlayCLITestCase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-46?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFCORE-46: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1144222, https://bugzilla.redhat.com/show_bug.cgi?id=1055229 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1144222) > Fix intermittent failures in DeploymentOverlayCLITestCase > --------------------------------------------------------- > > Key: WFCORE-46 > URL: https://issues.jboss.org/browse/WFCORE-46 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.0.0.Alpha9 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-83) EAR deployment overlay did not work if there is no related resource included in the ear

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-83?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFCORE-83: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1145364, https://bugzilla.redhat.com/show_bug.cgi?id=1055229 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1145364) > EAR deployment overlay did not work if there is no related resource included in the ear > --------------------------------------------------------------------------------------- > > Key: WFCORE-83 > URL: https://issues.jboss.org/browse/WFCORE-83 > Project: WildFly Core > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Stuart Douglas > Fix For: 1.0.0.Alpha6 > > Attachments: reproducer.zip > > > It is possible to overlay WEB-inf/lib/xy.jar without having xy.jar included in the war file. > If an EAR file is used a module in the lib directory can not be added in the same way. But overlay is working if the lib/xy.jar is available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2879) Remove duplicated code from test cases where custom modules are needed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2879?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2879: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1147390|https://bugzilla.redhat.com/show_bug.cgi?id=1147390] from ASSIGNED to POST > Remove duplicated code from test cases where custom modules are needed > ---------------------------------------------------------------------- > > Key: WFLY-2879 > URL: https://issues.jboss.org/browse/WFLY-2879 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 8.1.0.Final > Reporter: Pedro Igor > Assignee: Pedro Igor > > When writing some integration tests for the PicketLink subsystem, I've noticed that there is no utility class or API to make easier create and remove custom modules from the modules directory. > There are a few tests with this requirement, and most of them are replicating code. > After discussing with [~kabirkhan], he suggested to open this JIRA to review those test cases and make them use a reusable component to work with custom modules. > I've already wrote a class that I think can satisfy all test cases requiring a custom module. > See https://github.com/pedroigor/wildfly/blob/WFLY-2733/testsuite/integration.... > Usage example: https://github.com/pedroigor/wildfly/blob/WFLY-2733/testsuite/integration... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014