January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks

by Anuj Shah (JIRA)

Anuj Shah created JGRP-1908: ------------------------------- Summary: Optional Executing protocol behavior to not attempt to repeat tasks Key: JGRP-1908 URL: https://issues.jboss.org/browse/JGRP-1908 Project: JGroups Issue Type: Feature Request Reporter: Anuj Shah Assignee: Bela Ban As discussed on forum: http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le... {quote} I've noticed that runnable tasks submitted to the ExecutionService can be run more than once! This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc // The person currently servicing our request has gone down // without completing so we have to keep our request alive by // sending ours back to the coordinator The problem is that there is no guarantee that the request was not completed. For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout. I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though) Perhaps there could be control over the behaviour: * At least once - assumes task failed and resubmits * At most once - assumes task completed and cleans up - may not actually be complete * Exactly once - not sure if this is possible {quote} There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork: https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192... Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- Ondrej Kotek <okotek(a)redhat.com> changed the Status of [bug 1181086|https://bugzilla.redhat.com/show_bug.cgi?id=1181086] from ON_QA to VERIFIED > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-4289: --------------------------------- Assignee: Alessio Soldano (was: Darran Lofthouse) > Authentication bug on one-way JAX-WS methods > -------------------------------------------- > > Key: WFLY-4289 > URL: https://issues.jboss.org/browse/WFLY-4289 > Project: WildFly > Issue Type: Bug > Components: Security, Web Services > Affects Versions: 8.2.0.Final > Reporter: Jakub Grabowski > Assignee: Alessio Soldano > > 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. > 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. > 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. > 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. > It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4165) Invalidating another session removes the JSESSIONID cookie of the current session

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4165?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-4165. ---------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done > Invalidating another session removes the JSESSIONID cookie of the current session > --------------------------------------------------------------------------------- > > Key: WFLY-4165 > URL: https://issues.jboss.org/browse/WFLY-4165 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 8.2.0.Final > Environment: WildFly 8.1.0.Final and WildFly 8.2.0.Final on Windows 7 x64 > JDK 8u25 > Session storage set to Cookie > Reporter: Nicolas Grussenmeyer > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > When calling {{invalidate()}} on a HttpSession object of another session than the current one, the server sends back a "cookie expired" header {{Set-Cookie: JSESSIONID=XXXXXXXX; path=/; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT}} where XXXXXXXX is the session id of the invalidated session. > This results in the current JSESSIONID cookie being discarded by the browser, and the current session being lost. > I was able to narrow the "problem" in {{[io.undertow.servlet.spec.HttpSessionImpl:193|https://github.com/undertow-io/undertow/blob/1.0.15.Final/servlet/src/main/java/io/undertow/servlet/spec/HttpSessionImpl.java#L193]}} (in Undertow 1.0.15.Final), where the ServletRequestContext is taken from the ThreadLocal storage, returning the current request context instead of null (as the target session is not associated to the current ServletRequestContext ) > A workaround is to call {{invalidate()}} in a new Thread, so the retrieved ServletRequestContext is null -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-207: ---------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1099730|https://bugzilla.redhat.com/show_bug.cgi?id=1099730] from NEW to CLOSED > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-84) Jboss JMX: Operation failed with status WAITING

by Thorsten Kunz (JIRA)

[ https://issues.jboss.org/browse/REMJMX-84?page=com.atlassian.jira.plugin.... ] Thorsten Kunz commented on REMJMX-84: ------------------------------------- Not sure if this is still the right issue to post to or if there is another one for WildFly but the issue still persists in WildFly 8.2: {code} Caused by: java.lang.RuntimeException: Operation failed with status WAITING at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:240) ~[jboss-cli-client.jar:8.2.0.Final] at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:151) ~[jboss-cli-client.jar:8.2.0.Final] at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:102) ~[jboss-cli-client.jar:8.2.0.Final] at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:268) ~[na:1.7.0_65] at com.zabbix.gateway.JMXItemChecker.getValues(JMXItemChecker.java:95) ~[zabbix-java-gateway-2.2.5.jar:na] {code} The issue is still intermittent. JDK: java version "1.7.0_65" OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) OS: LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 6.5 (Santiago) Release: 6.5 Codename: Santiago > Jboss JMX: Operation failed with status WAITING > ------------------------------------------------ > > Key: REMJMX-84 > URL: https://issues.jboss.org/browse/REMJMX-84 > Project: Remoting JMX > Issue Type: Bug > Environment: jboss-as-7.1.1.Final on windows server > Reporter: Abhishek Apoorva > Assignee: David Lloyd > > Version : jboss-as-7.1.1.Final on windows server > I am getting below mentioned strange issue intermittently while fetching > Jboss JMX Mbean. > Can anyone help me to find the real cause of the issue? Secong thing is why it is coming intermittently either it should come always or it should not come at all. > JMXConnectorFactory.connect(serviceURL, environment); > While executing above mentioned line system is throwing below mentioned exception. > {noformat} > May 08 02:30:53:375 [DC#0, jboss] java.lang.RuntimeException: Operation failed with status WAITING > at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:216) > at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:143) > at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:94) > at javax.management.remote.JMXConnectorFactory.connect(Unknown Source) > at com.nimsoft.nimbus.probe.application.jboss.JmxConnection.createConnection(JmxConnection.java:68) > at com.nimsoft.nimbus.probe.application.jsr160.Entity.createConnection(Entity.java:1772) > at com.nimsoft.nimbus.probe.application.jsr160.Entity.getValue(Entity.java:1567) > at com.nimsoft.nimbus.probe.application.extractbase.Extract.processMonitor(Extract.java:1324) > at com.nimsoft.nimbus.probe.application.extractbase.Extract.processResource(Extract.java:1908) > at com.nimsoft.nimbus.probe.application.extractbase.Extract$DataCollector.run(Extract.java:1158) > at java.lang.Thread.run(Unknown Source) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-207: ---------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1099730|https://bugzilla.redhat.com/show_bug.cgi?id=1099730] from CLOSED to NEW > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-207: ---------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1099730|https://bugzilla.redhat.com/show_bug.cgi?id=1099730] from NEW to CLOSED > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Sven V (JIRA)

[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ] Sven V commented on WFLY-4289: ------------------------------ Yes, that's exactly the behaviour I have experienced. > Authentication bug on one-way JAX-WS methods > -------------------------------------------- > > Key: WFLY-4289 > URL: https://issues.jboss.org/browse/WFLY-4289 > Project: WildFly > Issue Type: Bug > Components: Security, Web Services > Affects Versions: 8.2.0.Final > Reporter: Jakub Grabowski > Assignee: Darran Lofthouse > > 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. > 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. > 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. > 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. > It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Jakub Grabowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ] Jakub Grabowski edited comment on WFLY-4289 at 1/27/15 6:21 AM: ---------------------------------------------------------------- And the code that demonstrates issue: {code} @Stateless @WebService @DeclareRoles("user") @Local(IMessageSender.class) @WebContext(authMethod = "BASIC") public class MessageSender implements IMessageSender { @RolesAllowed("user") @Oneway public void fails(long l) { System.out.println(">>>>>: " + l); } @RolesAllowed("user") public void works(long l) { System.out.println(">>>>>: " + l); } } {code} was (Author: jakub_grabowski): And the code that demonstrates issue: @Stateless @WebService @DeclareRoles("user") @Local(IMessageSender.class) @WebContext(authMethod = "BASIC") public class MessageSender implements IMessageSender { @RolesAllowed("user") @Oneway public void fails(long l) { System.out.println(">>>>>: " + l); } @RolesAllowed("user") public void works(long l) { System.out.println(">>>>>: " + l); } } > Authentication bug on one-way JAX-WS methods > -------------------------------------------- > > Key: WFLY-4289 > URL: https://issues.jboss.org/browse/WFLY-4289 > Project: WildFly > Issue Type: Bug > Components: Security, Web Services > Affects Versions: 8.2.0.Final > Reporter: Jakub Grabowski > Assignee: Darran Lofthouse > > 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. > 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. > 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. > 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. > It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

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 January 2015