March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-441) LDAP and GSSAPI tests are very slow

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-441?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-441: -------------------------------------- Probably already covered by this PR https://github.com/wildfly-security/wildfly-elytron/pull/372 > LDAP and GSSAPI tests are very slow > ----------------------------------- > > Key: ELY-441 > URL: https://issues.jboss.org/browse/ELY-441 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: David Lloyd > Priority: Minor > > The LDAP and GSSAPI tests are very slow, which slows down the devel/build/test cycle fairly substantially. See if there is a way to reduce the overhead of these tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6351) Improve error log on resolving interface

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFLY-6351: ---------------------------------------- Summary: Improve error log on resolving interface Key: WFLY-6351 URL: https://issues.jboss.org/browse/WFLY-6351 Project: WildFly Issue Type: Enhancement Reporter: Bartosz Baranowski Assignee: Jason Greene If IP6 is being used, without IP6 stack enabled, WFLY will notify that "it cant resolve", as to why? No indication. MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: WFLYSRV0082: failed to resolve interface public -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-897) Unable to authenticate in SPNEGO Login Module with NullPointerException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-897?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-897: -------------------------------------------------- Jiri Truhlar <jtruhlar(a)redhat.com> changed the Status of [bug 1236606|https://bugzilla.redhat.com/show_bug.cgi?id=1236606] from ON_QA to VERIFIED > Unable to authenticate in SPNEGO Login Module with NullPointerException > ----------------------------------------------------------------------- > > Key: SECURITY-897 > URL: https://issues.jboss.org/browse/SECURITY-897 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_2_3_6_Final > Environment: Red Hat JBoss EAP 6.3.2 > Reporter: Kunjan Rathod > Assignee: Chao Wang > Labels: jboss, jboss-as > Fix For: Negotiation_3_0_0_Final, Negotiation_2_3_11_Final > > > Description of problem: > The configuration with SPNEGO works fine, however from time to time the authentication fails with the following error: > ERROR (HTTP-341) [org.jboss.security.auth.spi.AbstractServerLoginModule] Unable to authenticate: java.lang.NullPointerException > at org.jboss.security.negotiation.spnego.SPNEGOLoginModule$AcceptSecContext.run(SPNEGOLoginModule.java:420) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:356) > Version-Release number of selected component (if applicable): > JBoss Security Negotiation 2.3.3.Final > How reproducible: > This happens very rarely (20 times in a day on a system where about 50 users are working) and it is extremely hard to reproduce. > Additional info: > At line 420 in [1], the GSSToken is null > ~~~~ > if (respToken != null) > { > NegotiationMessage response; > if (requestMessage instanceof KerberosMessage) > { > response = new KerberosMessage(Constants.KERBEROS_V5, respToken); > } > else > { > NegTokenTarg negTokenTarg = new NegTokenTarg(); > negTokenTarg.setResponseToken(respToken); > response = negTokenTarg; > } > ~~~~ > It looks like a GSSToken can be or is null, check the line#344 as follows:- > ~~~~~~~~~ > public Object run() > { > try > { > // The message type will have already been checked before this point so we know it is > // a SPNEGO message. > NegotiationMessage requestMessage = negotiationContext.getRequestMessage(); > // TODO - Ensure no way to fall through with gssToken still null. > byte[] gssToken = null; > if (requestMessage instanceof NegTokenInit) > { > ... > ~~~~~~~~~ > [1] : https://github.com/wildfly-security/jboss-negotiation/blob/2.3.3.Final/jb... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2024) Receiving messages out of order.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2024?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2024: -------------------------------- Sample configs {{udp-largecluster.xml}} and {{fast.xml}} are starting points, but this largely depends on what you want to do. Is it more Infinispan style traffic? Then UPerf is a good test, otherwise MPerf might be useful. I'd start the tuning process at the transport level and size the 2 thread pools accordingly. For example, if you disable the queue in the regular pool and up the max size, you'll get more concurrency. But again, it depends on * How many senders do you have? * Cluster size * Regular or OOB messages? * Blocking or non-blocking RPCs Further things to look at: * Can you compress data? -> {{COMPRESS}} * Flow control; possibly increase credits * UDP or TCP as transport? * Message batching (JGroups 4.0) * Type of message bundler in the transport * Run perf test and use probe to measure stats and adapt config * etc etc etc These are things we discuss in the workshop [1]. [1] http://www.jgroups.org/workshops.html > Receiving messages out of order. > -------------------------------- > > Key: JGRP-2024 > URL: https://issues.jboss.org/browse/JGRP-2024 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.7, 3.6.8 > Environment: RedHat 6.7 > Java 1.8.0 Update 45 > Reporter: Dylan Turnbull > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: jGroups Unit Test.zip, JGroupsMessageTest.java, jGroupsTestReciever.java > > > After splitting a file into smaller messages and send them down the channel the messages are received on the other side out of order. > Below is a sample output: > *+On the sender:+* > Sending... > Data Sent: > Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy te > ----------------------------------------------------- > Data Sent: > xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur > ----------------------------------------------------- > Data Sent: > vived not only five centuries, but also the leap into electronic typesetting, re > ----------------------------------------------------- > Data Sent: > d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passag > *+On the receiver:+* > Listening... > Data Received: > xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur > ----------------------------------------------------- > Data Received: > vived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularise > ----------------------------------------------------- > Data Received: > d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing so > ----------------------------------------------------- > Data Received: > ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so > ----------------------------------------------------- > Data Received: > ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so > ----------------------------------------------------- -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6348) upgrade org.jboss.spec.javax.el:jboss-el-api_3.0_spec to 1.0.6.Final

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6348?page=com.atlassian.jira.plugin.... ] Scott Marlow reassigned WFLY-6348: ---------------------------------- Assignee: Scott Marlow (was: Jason Greene) > upgrade org.jboss.spec.javax.el:jboss-el-api_3.0_spec to 1.0.6.Final > -------------------------------------------------------------------- > > Key: WFLY-6348 > URL: https://issues.jboss.org/browse/WFLY-6348 > Project: WildFly > Issue Type: Component Upgrade > Components: EE > Reporter: Bartosz Baranowski > Assignee: Scott Marlow > Fix For: 10.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6348) upgrade org.jboss.spec.javax.el:jboss-el-api_3.0_spec to 1.0.6.Final

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6348?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-6348: ------------------------------- Fix Version/s: 10.1.0.Final > upgrade org.jboss.spec.javax.el:jboss-el-api_3.0_spec to 1.0.6.Final > -------------------------------------------------------------------- > > Key: WFLY-6348 > URL: https://issues.jboss.org/browse/WFLY-6348 > Project: WildFly > Issue Type: Component Upgrade > Components: EE > Reporter: Bartosz Baranowski > Assignee: Jason Greene > Fix For: 10.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6348) upgrade org.jboss.spec.javax.el:jboss-el-api_3.0_spec to 1.0.6.Final

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6348?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-6348: ------------------------------- Component/s: EE > upgrade org.jboss.spec.javax.el:jboss-el-api_3.0_spec to 1.0.6.Final > -------------------------------------------------------------------- > > Key: WFLY-6348 > URL: https://issues.jboss.org/browse/WFLY-6348 > Project: WildFly > Issue Type: Component Upgrade > Components: EE > Reporter: Bartosz Baranowski > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ] Scott Marlow updated JBEE-161: ------------------------------ Fix Version/s: jboss-jstl-api_1.2_spec-1.0.6.Final > BeanELResolver does not support methods that use varargs > -------------------------------------------------------- > > Key: JBEE-161 > URL: https://issues.jboss.org/browse/JBEE-161 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-el-api > Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1 > Reporter: Ingo Weiss > Assignee: Carlo de Wolf > Labels: el > Fix For: jboss-el-api_3.0_spec-1.0.6.Final > > Attachments: beanELResolver4VarArgs.zip > > > When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception: > {code} > java.lang.IllegalArgumentException: wrong number of arguments > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834) > at javax.el.BeanELResolver.invoke(BeanELResolver.java:527) > at org.apache.el.parser.AstValue.getValue(AstValue.java:156) > at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32) > at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ] Scott Marlow updated JBEE-161: ------------------------------ Fix Version/s: jboss-el-api_3.0_spec-1.0.6.Final (was: jboss-jstl-api_1.2_spec-1.0.6.Final) > BeanELResolver does not support methods that use varargs > -------------------------------------------------------- > > Key: JBEE-161 > URL: https://issues.jboss.org/browse/JBEE-161 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-el-api > Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1 > Reporter: Ingo Weiss > Assignee: Carlo de Wolf > Labels: el > Fix For: jboss-el-api_3.0_spec-1.0.6.Final > > Attachments: beanELResolver4VarArgs.zip > > > When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception: > {code} > java.lang.IllegalArgumentException: wrong number of arguments > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834) > at javax.el.BeanELResolver.invoke(BeanELResolver.java:527) > at org.apache.el.parser.AstValue.getValue(AstValue.java:156) > at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32) > at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5993) Testcase for WFCORE-1226 "undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler"

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-5993?page=com.atlassian.jira.plugin.... ] Chao Wang updated WFLY-5993: ---------------------------- Summary: Testcase for WFCORE-1226 "undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler" (was: Add a testcase for WFCORE-1226 "undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler") Original Estimate: 0 minutes Remaining Estimate: 0 minutes > Testcase for WFCORE-1226 "undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler" > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5993 > URL: https://issues.jboss.org/browse/WFLY-5993 > Project: WildFly > Issue Type: Task > Components: Test Suite > Affects Versions: 10.0.0.CR5 > Reporter: Chao Wang > Assignee: Chao Wang > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > since it's on wildfly-core 2.0.6.Final already, this adds a testcase for WFCORE-1226 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 March 2016