[JBoss JIRA] (JGRP-1634) LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1634?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1634:
--------------------------------
OK, I'll take a look, thx
> LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1634
> URL: https://issues.jboss.org/browse/JGRP-1634
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Environment: JGroups 3.3.0 Final
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: AbstractJdkLockManager.java, DistributedJGroupsLockManager.java, jgroups.xml, LockingTest.java
>
>
> We upgraded from 3.3.0.CR1 to 3.3.0.Final and began to experience all sorts of weird lock acquisition issues. The symptoms are:
> (a) tryLock() randomly hangs
> (b) tryLock(timeout) times out, without acquiring the lock (even though it should, as the lock is only requested from a single node)
> This happens both with CENTRAL_LOCK as well as PEER_LOCK. I have attached the configuration we are using.
> 3.3.0.CR1 worked fine. This bug seems to have been introduced by JGRP-1610. I have carefully reviewed the code changes introduced by said fix, and they seems to be:
> (i) OOB used for lock messages. This should not be causing problems.
> (ii) Use of a striped ReentrantLock table instead of synchronized blocks. By itself, this change alone should not be causing problems.
> (iii) Much, much more tightening locking around the server lock table. I think this is where something goes wrong, and deadlocks end up occuring.
> The following methods on Locking.java did not even have a synchronized block before, and now they are protected with the striped ReentrantLocks:
> - handleLockRequest()
> - handleAwaitRequest()
> - handleDeleteAwaitRequest()
> - handleSignalRequest()
> This is the major change I see which could introduce deadlocks. Other methods which were already synchronized before (handleCreateLockRequest, handleDeleteLockRequest, handleCreateAwaitingRequest, handleDeleteAwaitingRequest) now are stripe-locked, which should not be the cause of problems.
> I would have liked to be able to indicate steps to reproduce, but it is quite random, although the bug is consistent enough that we can see it every single time we deploy our app.
--
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
10 years, 11 months
[JBoss JIRA] (JGRP-1636) java.lang.ArrayIndexOutOfBoundsException when trying to accure lock
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1636?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1636:
---------------------------
Fix Version/s: 3.4
> java.lang.ArrayIndexOutOfBoundsException when trying to accure lock
> -------------------------------------------------------------------
>
> Key: JGRP-1636
> URL: https://issues.jboss.org/browse/JGRP-1636
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Environment: Ubuntu 12.10 , kernel 3.5.0-26-generic SMP
> Reporter: Tim Tim
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Getting java.lang.ArrayIndexOutOfBoundsException
> java.lang.ArrayIndexOutOfBoundsException: -4
> at org.jgroups.protocols.Locking._getLock(Locking.java:355)
> at org.jgroups.protocols.Locking.handleLockRequest(Locking.java:424)
> that happens when lock_name.hashCode() < 0
> protected Lock _getLock(String lock_name) {
> int index=lock_name != null? lock_name.hashCode() % locks.length : 0;
> return locks[index];
> }
--
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
10 years, 11 months
[JBoss JIRA] (JGRP-1635) RELAY2: Allow for load balancing for received messages among the local cluster
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1635?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1635:
---------------------------
Fix Version/s: 3.4
I suspect this needs to be in a 3.2.x version as well ?
> RELAY2: Allow for load balancing for received messages among the local cluster
> -------------------------------------------------------------------------------
>
> Key: JGRP-1635
> URL: https://issues.jboss.org/browse/JGRP-1635
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.2.9
> Reporter: Erik Salter
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> I've prototyped a configuration option that load-balances applying the changes from a remote SiteMaster across all local nodes in a cluster.
> There is still a single SiteMaster (thereby not breaking the existing JGroups model); the difference is that the messages are now forwarded to other nodes in the local cluster and delivered to the application layer there for unmarshalling and processing.
--
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
10 years, 11 months
[JBoss JIRA] (AS7-887) Support legacy ServiceMBeans in SAR deployments
by rajesh k (JIRA)
[ https://issues.jboss.org/browse/AS7-887?page=com.atlassian.jira.plugin.sy... ]
rajesh k commented on AS7-887:
------------------------------
Sorry I am bothing you as I dont have support and I have to stick to EAP 6.0.1. I need your help on couple of thing we came across during migration. I went through many jboss community forums as well on below issue.
We are migrating app from Websphere to Jboss 6.0.1 EAP. We have websphere's workmanager feature which needs to be migrate using commonj. I tried to foo-commonj.sar to make use of workmanager features from ejb in Jboss 6.0.1 EAP. I used previous versions support jars to register commonj jndi in Jboss 6.0.1 EAP.
will we able to use Commonj within EJB in JBoss 6.0.1 EAP as EJB spec prohibits to create threads within EJB due to vendor licencing issues.
Pl help me in this.
Regards,
Rajesh.
> Support legacy ServiceMBeans in SAR deployments
> -----------------------------------------------
>
> Key: AS7-887
> URL: https://issues.jboss.org/browse/AS7-887
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JMX
> Reporter: Matt Drees
> Assignee: Eduardo Martins
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> It looks like the current SAR deployment code (jboss-as-sar) will deploy simple MBeans just fine. However, users may expect to be able to deploy older ServiceMBeans from previous Jboss AS versions. Currently, attempting to do this results in a ClassNotFoundException, since the org.jboss.system.ServiceMBean interface doesn't exist anymore.
> Ideally this would also involve supporting ServiceMBeans that extend org.jboss.system.ServiceMBeanSupport, which also doesn't exist anymore.
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-1390) Undertow: javamelody SessionListener stop working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1390?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1390:
--------------------------------------
This is not a javamelody problem, and is certainly not a session listener problem. I added Javamelody to a sample app with your web.xml and it works fine.
[code]
Caused by: java.util.concurrent.TimeoutException: JBAS017345: Timeout context service activation: service jboss.undertow.deployment.default-host./jaffa
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$ContextActivatorImpl.start(UndertowDeploymentService.java:158)
at org.jboss.as.osgi.web.WebContextLifecycleInterceptor.invoke(WebContextLifecycleInterceptor.java:100)
[code]
This is an OSGi web context deployment failure. You are going to have to give me an actual sample application that reproduces the problem for me to debug it.
> Undertow: javamelody SessionListener stop working
> -------------------------------------------------
>
> Key: WFLY-1390
> URL: https://issues.jboss.org/browse/WFLY-1390
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Igor Shulika
> Assignee: Stuart Douglas
> Attachments: jaffa-3rd-party-javamelody-core-1.43.0.jar
>
>
> I'm deploying JavaMelody OSGi bundle on the latest WildFly 8.0.0.Alpha2-SNAPSHOT server. Since I switch from Jbossweb to Undertow the JavaMelody SessionListener stop working.
> Please see below configuration in the web.xml file.
> <listener>
> <listener-class>net.bull.javamelody.SessionListener</listener-class>
> </listener>
> Please see error trace below.
> Note: It works in Jbossweb.
> Thanks!
> 09:51:44,005 INFO [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011001: Bundle installed: org.test.sample.webapp.my-sample-webapp:6.0.0
> 09:52:15,221 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-10) MSC000001: Failed to start service jboss.deployment.unit."my-sample-webapp-6.0.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."my-sample-webapp-6.0.jar".Activate: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1930) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.osgi.deployment.interceptor.LifecycleInterceptorException: JBAS017345: Timeout context service activation: service jboss.undertow.deployment.default-host./test
> at org.jboss.as.osgi.web.WebContextLifecycleInterceptor.invoke(WebContextLifecycleInterceptor.java:105)
> at org.jboss.osgi.deployment.interceptor.AbstractLifecycleInterceptorService.handleStateChange(AbstractLifecycleInterceptorService.java:264)
> at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:253)
> at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:242)
> at org.jboss.osgi.framework.internal.UserBundleState.startInternalNow(UserBundleState.java:637)
> at org.jboss.osgi.framework.internal.UserBundleState.startInternal(UserBundleState.java:526)
> at org.jboss.osgi.framework.internal.BundleManagerPlugin.startBundle(BundleManagerPlugin.java:560)
> at org.jboss.as.osgi.deployment.BundleActivateProcessor$BundleActivateService.start(BundleActivateProcessor.java:125)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> ... 3 more
> Caused by: java.util.concurrent.TimeoutException: JBAS017345: Timeout context service activation: service jboss.undertow.deployment.default-host./jaffa
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$ContextActivatorImpl.start(UndertowDeploymentService.java:158)
> at org.jboss.as.osgi.web.WebContextLifecycleInterceptor.invoke(WebContextLifecycleInterceptor.java:100)
> ... 12 more
--
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
10 years, 11 months
[JBoss JIRA] (JGRP-1634) LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-1634?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento updated JGRP-1634:
---------------------------------------------
Attachment: AbstractJdkLockManager.java
DistributedJGroupsLockManager.java
LockingTest.java
Hi Bela, I have been able to reproduce both problems (a) and (b) as described above, with a simple test. I have attached our own classes that wrap JGroups locking functionality, as well as LockingTest.java which contains a main method.
The test uses the attached jgroups.xml, and generates many locking requests for different locks simultaneously. With 3.3.0.CR1 it works fine, and locks are always acquired (they are randomnly generated strings).
With 3.3.0.Final, after a while, the locks are randomly no longer acquired (tryLock fails), and eventually no locks are obtained at all. This reproduces issue (b) as originally described.
If you modify DistributedJGroupsLockManager.DEFAULT_TRY_LOCK_TIMEOUT to zero, then our class uses regular tryLock() instead of tryLock(timeout). This allows testing issue (a) as described before. So when you launch main, what happens is that at first, locks are acquired normally, and after a while, and threads hang on Object.wait() as shown the the Eclipse debugger.
> LockingService.tryLock() randomly hangs, and tryLock(timeout) does not acquire the lock even though it is free to be taken
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1634
> URL: https://issues.jboss.org/browse/JGRP-1634
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Environment: JGroups 3.3.0 Final
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: AbstractJdkLockManager.java, DistributedJGroupsLockManager.java, jgroups.xml, LockingTest.java
>
>
> We upgraded from 3.3.0.CR1 to 3.3.0.Final and began to experience all sorts of weird lock acquisition issues. The symptoms are:
> (a) tryLock() randomly hangs
> (b) tryLock(timeout) times out, without acquiring the lock (even though it should, as the lock is only requested from a single node)
> This happens both with CENTRAL_LOCK as well as PEER_LOCK. I have attached the configuration we are using.
> 3.3.0.CR1 worked fine. This bug seems to have been introduced by JGRP-1610. I have carefully reviewed the code changes introduced by said fix, and they seems to be:
> (i) OOB used for lock messages. This should not be causing problems.
> (ii) Use of a striped ReentrantLock table instead of synchronized blocks. By itself, this change alone should not be causing problems.
> (iii) Much, much more tightening locking around the server lock table. I think this is where something goes wrong, and deadlocks end up occuring.
> The following methods on Locking.java did not even have a synchronized block before, and now they are protected with the striped ReentrantLocks:
> - handleLockRequest()
> - handleAwaitRequest()
> - handleDeleteAwaitRequest()
> - handleSignalRequest()
> This is the major change I see which could introduce deadlocks. Other methods which were already synchronized before (handleCreateLockRequest, handleDeleteLockRequest, handleCreateAwaitingRequest, handleDeleteAwaitingRequest) now are stripe-locked, which should not be the cause of problems.
> I would have liked to be able to indicate steps to reproduce, but it is quite random, although the bug is consistent enough that we can see it every single time we deploy our app.
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-1407) Correct test methods dependency in EjbMethodInterceptorTestCase
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1407?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1407:
-----------------------------------------------
Chao Wang <chaowan(a)redhat.com> made a comment on [bug 968781|https://bugzilla.redhat.com/show_bug.cgi?id=968781]
Description of problem:
org.jboss.as.test.integration.ejb.interceptor.method.EjbMethodInterceptorTestCase failed intermittently due to dependency of test ordering on https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-T...
This test assumes testMethodLevelInterceptors() run at first which does not contain variable TopSecretInterceptor.called reset to false at beginning like second test method does. If test run in different order, then it will fail, should isolate this "connection" between test methods.
Version-Release number of selected component (if applicable):
EAP 6.1.1
How reproducible:
Use @InSequence to run testMethodOverloaded() before testMethodLevelInterceptors(), then test will fail.
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
No dependency between test order.
Additional info:
> Correct test methods dependency in EjbMethodInterceptorTestCase
> ---------------------------------------------------------------
>
> Key: WFLY-1407
> URL: https://issues.jboss.org/browse/WFLY-1407
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
> Fix For: 8.0.0.Alpha2
>
> Attachments: failure-stacktrace.txt, WFLY-1407.patch
>
>
> org.jboss.as.test.integration.ejb.interceptor.method.EjbMethodInterceptorTestCase failed intermittently due to dependency of test ordering on https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-T...
> In upstream code, its bean fixed by forcing test running in order, however, the real issue behind is that it assumes testMethodLevelInterceptors() run at first which does not contain variable TopSecretInterceptor.called reset to false at beginning like second test method does.
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-1419) Overrides REST Response Object on Status 404
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/WFLY-1419?page=com.atlassian.jira.plugin.... ]
Aslak Knutsen commented on WFLY-1419:
-------------------------------------
Confirmed fixed by https://github.com/undertow-io/undertow/commit/abe2c9e5db323e886ccbe29d2a...
{code}
DEBUG [org.apache.http.wire] >> "GET /51a81fcd-f552-4c04-82cf-dffb9cbb12ae/api/conference/29332d00-61cb-4820-adf5-cacd0df7b50f HTTP/1.1[\r][\n]"
DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml; type=conference[\r][\n]"
DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
DEBUG [org.apache.http.wire] >> "[\r][\n]"
DEBUG [org.apache.http.wire] << "HTTP/1.1 404 Not Found[\r][\n]"
DEBUG [org.apache.http.wire] << "Connection: keep-alive[\r][\n]"
DEBUG [org.apache.http.wire] << "Content-Type: application/vnd.ced+xml; type=conference[\r][\n]"
DEBUG [org.apache.http.wire] << "Content-Length: 0[\r][\n]"
{code}
> Overrides REST Response Object on Status 404
> --------------------------------------------
>
> Key: WFLY-1419
> URL: https://issues.jboss.org/browse/WFLY-1419
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Environment: JBoss AS 7.1.1, JBoss EAP 6.1.0, WildFly 8.0.0.Alpha1
> Linux, Java 1.7
> Reporter: Aslak Knutsen
> Assignee: Stuart Douglas
>
> *Given*:
> {code:title=JAX-RS Resource Code}
> @Path("/conference")
> public class ConferenceResource implements Resource {
> private static final String BASE_MEDIA_TYPE = "application/vnd.ced+xml";
> private static final String CONFERENCE_MEDIA_TYPE = BASE_MEDIA_TYPE + ";type=conference";
> private static final String SESSION_MEDIA_TYPE = BASE_MEDIA_TYPE + ";type=session";
> ...
> @GET
> @Path("/{id}")
> @Produces("application/vnd.ced+xml")
> public Response get(@PathParam("id") String id) {
> Conference conference = repository.get(id);
> if(conference == null) {
> return Response.status(Status.NOT_FOUND).type(CONFERENCE_MEDIA_TYPE).build();
> }
> return Response.ok(
> new ConferenceRepresentation(conference, uriInfo.getAbsolutePathBuilder()))
> .type(CONFERENCE_MEDIA_TYPE).build();
> }
> ...
> }
> {code}
> *Then*:
> The Body and MediaType is overwritten by the WebContainer and standard text/html Error Page is returned.
> {code:title=Wire Log}
> DEBUG [org.apache.http.wire] >> "GET /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 200 OK[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Type: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Length: 422[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:54:22 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] << "<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns3:conference xmlns:ns2="urn:ced:link" xmlns:ns3="urn:ced:conference"><ns2:link href="http://127.0.0.1:8080/c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference..." rel="session"/><end>2013-05-29T04:54:22.213+02:00</end><name>Test</name><start>2013-05-29T04:54:22.213+02:00</start><tagLine>Tagline</tagLine></ns3:conference>"
> DEBUG [org.apache.http.wire] >> "DELETE /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: */*[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Content-Length: 0[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 204 No Content[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:55:44 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] >> "GET /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 404 Not Found[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Type: text/html;charset=utf-8[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Length: 956[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:55:45 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] << "<html><head><title>JBoss Web/7.0.13.Final - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested resource () is not available.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></htm!
l>"
> HTTP/1.1 404 Not Found
> Server=Apache-Coyote/1.1
> Content-Type=text/html;charset=utf-8
> Content-Length=956
> Date=Wed, 29 May 2013 02:55:45 GMT
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head>
> <title>
> JBoss Web/7.0.13.Final - Error report
> </title>
> <style>
> <!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}-->
> </style>
> </head>
> <body>
> <h1>
> HTTP Status 404 -
> </h1>
> <hr noshade="noshade" size="1"/>
> <p>
> <b>
> type
> </b>
> Status report
> </p>
> <p>
> <b>
> message
> </b>
> <u/>
> </p>
> <p>
> <b>
> description
> </b>
> <u>
> The requested resource () is not available.
> </u>
> </p>
> <hr noshade="noshade" size="1"/>
> <h3>
> JBoss Web/7.0.13.Final
> </h3>
> </body>
> </html>
> {code}
> *Expected*: Return the JAX-RS Response Object as defined by the JAX-RS Service.
--
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
10 years, 11 months