[JBoss JIRA] (AS7-4428) Arquillian: IllegalStateException: standard-sockets -> http -> bound-port is undefined
by Ondrej Zizka (JIRA)
Ondrej Zizka created AS7-4428:
---------------------------------
Summary: Arquillian: IllegalStateException: standard-sockets -> http -> bound-port is undefined
Key: AS7-4428
URL: https://issues.jboss.org/browse/AS7-4428
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Reporter: Ondrej Zizka
Assignee: Ondrej Zizka
This happens sometimes in QA lab, probably due to slowness.
See https://hudson.qa.jboss.com/hudson/job/AS7-TS-valid-mvn-all-ipv6/56/testR...
{code}
java.lang.RuntimeException: java.lang.IllegalStateException: standard-sockets -> http -> bound-port is undefined
at org.jboss.as.arquillian.container.ManagementClient.getBinding(ManagementClient.java:222)
at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:111)
at org.jboss.as.arquillian.container.ManagementClient.getDeploymentMetaData(ManagementClient.java:117)
at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:150)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:156)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:123)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:266)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:122)
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.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.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
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.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:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:90)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:79)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:258)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:234)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:78)
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.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:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
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.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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
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.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.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.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:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
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:300)
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)
Caused by: java.lang.IllegalStateException: standard-sockets -> http -> bound-port is undefined
at org.jboss.as.arquillian.container.ManagementClient.defined(ManagementClient.java:193)
at org.jboss.as.arquillian.container.ManagementClient.getBinding(ManagementClient.java:218)
... 96 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5732) JAX-WS call is returning Status 403 - Access to the requested resource has been denied
by Fernando Rubbo (JIRA)
Fernando Rubbo created AS7-5732:
-----------------------------------
Summary: JAX-WS call is returning Status 403 - Access to the requested resource has been denied
Key: AS7-5732
URL: https://issues.jboss.org/browse/AS7-5732
Project: Application Server 7
Issue Type: Bug
Reporter: Fernando Rubbo
Priority: Blocker
Hi
I'm facing an issue whenever a WS call (which have a security context) is being made. The problem is:
When user/pass are not provided by the client the server respond:
HTTP Status 401 -This request requires HTTP authentication ()
When user/pass are provided the server respond:
HTTP Status 403 - Access to the requested resource has been denied
In Jboss 4.2 it works as expected.
On other words. It make the call and authenticate the user.
I've attached two files in the forum (https://community.jboss.org/message/763547#763547). An eclipse EJB project and the standalone.xml file.
Please, fix this issue. We need this to finish our migration from JBoss 4.2 to JBoss 7
--
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
13 years, 9 months
[JBoss JIRA] Created: (JGRP-1317) STABLE: compress STABLE messages
by Bela Ban (JIRA)
STABLE: compress STABLE messages
--------------------------------
Key: JGRP-1317
URL: https://issues.jboss.org/browse/JGRP-1317
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12.2, 3.1
For large clusters, stable messages are quite large, and should be compressed.
E.g.:
- Don't send the entire view (with all members), but only the ViewId, then the indices of a digest array would point to the rank of a member within the referred-to ViewId
- A digest has 3 longs (low, highest_received and highest_delivered). Do we need all 3 every time ?
- Compress the 3 longs into 1 long and 2 shorts: the latter 2 are offsets from the first seqno
- Use a bit set (consisting of a variable number of ints) to set the 3 variables
- If we have a digest (0), 0, 0: send a special marker
- Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (JGRP-100) Large-scale JGroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-100?page=com.atlassian.jira.plugin.s... ]
Bela Ban updated JGRP-100:
--------------------------
Fix Version/s: 3.x
(was: 3.3)
Pushed into 3.x as this is an ongoing task
> Large-scale JGroups
> -------------------
>
> Key: JGRP-100
> URL: https://issues.jboss.org/browse/JGRP-100
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.x
>
>
> - Run JGroups on hundreds of nodes (either physical, or simulation).
> - Determine a protocol stack that can be used for large-scale execution
> - Example:
> - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will
> be generated
> - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion)
> - Look at PBCAST
--
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
13 years, 9 months
[JBoss JIRA] Created: (JGRP-1052) Ergonomics
by Bela Ban (JIRA)
Ergonomics
----------
Key: JGRP-1052
URL: https://jira.jboss.org/jira/browse/JGRP-1052
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.0
The goal is to (a) reduce the number of properties needed and (b) determine the values dynamically.
Examples:
- Determine the best min/max size of a thread pool
- Find out what the best timeout values are for retransmission, e.g. based on average retransmission times
- Determine the optimal number of credits in FC
This is similar to the JVM setting where, starting with 1.5, the initial values can be set, but over time, the JVM dynamically changes them.
In the best case, a config contains only a list of protocols without any properties, and JGroups will figure out the correct values.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (JGRP-1523) FD_ALL does not unsuspect on heartbeat
by Jan Boehm (JIRA)
Jan Boehm created JGRP-1523:
-------------------------------
Summary: FD_ALL does not unsuspect on heartbeat
Key: JGRP-1523
URL: https://issues.jboss.org/browse/JGRP-1523
Project: JGroups
Issue Type: Quality Risk
Affects Versions: 3.0.14
Reporter: Jan Boehm
Assignee: Bela Ban
FD_ALL stores suspected nodes in "suspected_mbrs" when it receives no heartbeats. If it does not predict the local node as new coordinator it does not pass this suspicion upwards. Since UNSUSPECT from upwards is the only event that removes a node from suspected_mbrs the set retains all nodes except the nodes that where newly suspected when local became the potential new coordinator.
This seems wasteful and wrong (it leads to wrong results if there are "stale" suspects that would be preferred as new coordinators). The timestamps for nodes in suspected_mbrs should be rechecked in FD_ALL.suspect before adding the new nodes.
--
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
13 years, 9 months