I'm having trouble with a jersey application running on a jetty server that will take up to 30 seconds to start. I don't know what causes this behaviour, and I'm unsure how to debug it.
Jersey is not started until the first HTTP request to one of its services are made. After the first request is made, the following gets printed:
INFO: Initiating Jersey application, version 'Jersey: 1.3 06/17/2010 04:53 PM'
After that, 5 to 45 seconds pass, and then jersey prints info about what resources it found and replies to the HTTP request.
First, I'd like to force jersey to start when the rest of the app starts as a hack to get around this until I find the culprit. Is there any way to do that without emulating an actual HTTP request to jetty?
Second, I'm stumped as to how to debug this. I've checked the constructors in my service classes, and they don't appear to be responsible. Has anyone had similar problems with jersey?
You could try the following in your web.xml:
<servlet>
<servlet-name>ServletAdaptor</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
I'm not sure why there'd be a long delay - perhaps it's doing some form of check for updates - are you able to monitor the http traffic from your application? Glassfish does that and it can take a while.
Related
I have a web application running on Wildfly 26 that uses SSE broadcasting and works correctly with http. However, when I switch to using an https endpoint, I get Wildfly log entries of:
WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1)
RESTEASY002186: Failed to set servlet request into asynchronous mode,
server sent events may not work
This happens with each registration attempt of the https endpoint but I never see this when registering with the http endpoint.
Testing with curl against the http endpoint results in curl waiting for events to show up (and keeps printing them out as it receives them) until I quit. Using curl to test the https endpoint, I will see the same headers I got from the http endpoint, namely:
HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: text/event-stream
But after printing out my registration successful event, curl seems to believe the stream is closed and exits -- giving me my command prompt back.
My #GET MediaType.SERVER_SENT_EVENTS registration endpoint will create an OutboundSseEvent and send it to the SseEventSink to acknowledge successful registration to my SseBroadcaster instance (this is the event curl sees and prints before exiting). I then log a registration successful message before exiting the method. All of this appears to work correctly for both http and https but the stream doesn't stay open once the request endpoint completes because of the failure to run asynchronously as outlined above.
I have not found information on the causes and/or workaround solutions for my RESTEASY002186 problem. I posted a question on this issue last week using the Wildfly Google Group (https://groups.google.com/g/wildfly/c/SO2eHdvMEko) but thought I would try a wider audience since this doesn't seem to be a commonly experienced condition. I don't see any indications during initialization that WildFly will be unable to use asynchronous mode, it just complains when it tries and fails... Any help would be greatly appreciated!
Edit 6/6/2022
The code is running on an isolated network so I can't just cut/paste the code here, but I gutted the resources file to a bare minimum -- just leaving enough for the client to be able to register. The problem remains unchanged. The code is now essentially:
#Path("sse")
public class SseResources {
#GET
#Produces(MediaType.SERVER_SENT_EVENTS)
public void listen(#Context Sse sse, #Context SseEventSink sseEventSink) {
SseRegComplete regComplete = new SseRegComplete("sse-server");
OutboundSseEvent event = sse.newEventBuilder().
name(regComplete.getType().toString()).
id(regComplete.getEventId()).
mediaType(MediaType.APPLICATION_JSON_TYPE).
data(SseRegComplete.class, regComplete).
comment("Event Stream Registration Completed Successfully").
build();
sseEventSink.send(event);
}
}
Before the above simplified code, I had declared the resource as #ApplicationScoped, had Sse injected into it, and kept a reference to the SseBroadcaster so I could use it whenever an event would come in. I was catching the events to broadcast by using an #Observes method (which I also got rid of). I was calling register(sseEventSink) on the SseBroadcaster in the listen method so I could later call broadcast(outboundEvent) whenever I had updates to publish. I got rid of all that just to see if I could get the stream to stay open but to no avail. I still get the RESTEASY002186 message and curl still exits after printing out the regComplete event sent to it in the code above.
Edit 6/7/2022
Yesterday I was able to get my code working in a new vanilla Wildfly 26 install using an https endpoint URL by following these configuration instructions. Something I hadn't mentioned in the original post is that I am trying to add SSE functionality to an already existing app. It is several years old and we actually moved to Wildfly 26 about 6 months ago because of the log4j vulnerability in the earlier version of Wildfly we were using. I suspect that the problem is related to either our Wildfly configuration (perhaps because old settings were brought over that shouldn't have been) or some 3rd party dependency that is preventing Wildfly from using asynchronous mode.
We are using Shiro for authentication and authorization against an LDAP server -- perhaps Shiro has some hooks into the Wildfly runtime that are causing issues? After initial login, we use a session cookie in all subsequent calls. That is a difference from my test server but I don't think it is relevant because the call definitely passed authentication before executing the registration code. The only other thing that comes to mind right now is our web app ships with LogBack and tells Wildfly not to use the default logging framework.
I plan to start today by comparing the two standalone.xml files to see if anything jumps out at me as being fundamentally different. Is there anything else I should be checking for differences (I think there is a domain.xml file somewhere...)?
Edit 6/14/2022
This definitely has something to do with Shiro being in the loop. When I edit the web.xml file to have Shiro's filter-mapping url-pattern to not include the SSE endpoint, everything works as expected.
I found that weblogic defaults to a context "/weblogic/", there is nothing in this page, what does this do?enter image description here
When you hit /weblogic, you hit the ReadyApp monitoring servlet under /weblogic/ready context.
In short, this servelet exposes the status of your applications deployed in your application server.
Http code 200 means that your server and your app are started and ready to handle incoming requests.
You can read details about the ReadyApp framework in this documentation.
I have a need to obtain all the incoming and outgoing stream names from Ant Media Server, so as to process them uniquely. Is there any way in which we can obtain those, with any specific programming language like python or Java?? Thanks in advance.
You can get all stream information using "getBroadcastList" rest service. This rest service produces information as JSON messages. "name" fields include Stream names.
Usage: http://[SERVER_ADDR]:5080//rest/broadcast/getList/[offset]/[size]
Example: http://[SERVER_ADDR]:5080/LiveApp/rest/broadcast/getList/0/10
You can consume this rest service in any programming language. Please note that you need to call this rest service either from the local machine which Ant Media Server is running on or from remote after successfully logged in to management panel due to the security reasons.
If you want to remove this filtering mechanism please remove the below lines from webapps-> {Application} -> WEBINF -> web.xml
<filter>
<filter-name>RestAuthenticationFiler</filter-name>
<filter-class>io.antmedia.serverapp.pscp.filter.RestAuthenticationFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>RestAuthenticationFiler</filter-name>
<url-pattern>/rest/*</url-pattern>
</filter-mapping>
I have been going through the google tutorial ( which I find very good ) at
https://developers.google.com/web-toolkit/doc/latest/tutorial/RPC
I have the service up and running on my local server and my JavaScript client can call it fine. OK so far. Now, what I want to do is deploy the service on a remote server JoeSoapHost:8080
How do I now tell my client where to send it's requests? I can't see any server/url being created in my RPC call. It just works by magic but now I want to get under the bonnet and start breaking it.
[Edit}
This is the Interface my client uses to know what service on the Server is to be called. I know that my Web.xml web descriptor must have a url that matches this. It has this because my server is invoked ok. Problem is, if I now decide to deploy my server elsewhere how do I tell my client what server/domain name to use?
#RemoteServiceRelativePath("stockPrices")
public interface StockPriceService extends RemoteService
{
StockPrice[] getPrices(String[] symbols);
}
What I want to achieve first is have a simple GWT client calling into an RPC service. I have this working but only when the server is localhost.
Next step, I deploy my app to the Google App Engine. What must I change now because my RPC service in my JavaScript is not being called when I deploy my app to
http://stockwatcherjf.appspot.com/StockWatcher.html
1) Brian Slesinsky excellent document on RPC - https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit#heading=h.amx1ddpv5q4m
2) #RemoteServiceRelativePath("stockPrices") allows GWT code to determine relative to your host/server/domain i.e http//mydomain.com/gwtapp/stockPrices
3) You can search GOOGle IO Sessions from 2009 - 2012 for some more in depth stuff on GWT RPC usage.
#RemoteServiceRelativePath gives the path of the servlet relative to the GWT.getModuleBaseURL() (which is more or less the URL of the *.nocache.js script); it doesn't "just work by magic".
If you deploy your services on a different server than the one serving your client code, then you'll likely hit the Same Origin Policy. CORS can help here, but you'll lose compatibility with IE (up to IE9 included). You'd better stick serving everything from the same origin.
I've developed an WS using Axis2 1.4 and glassfish 2.1.1, which is properly running using the endpoint url like
`http://server:port/appname/services/FooService`
but I need to get it working through an endpoint like
`http://server:port/FooService`
since the WS clients can't be changed to use a different endpoint.
Getting rid of the "appname" part was easy, setting the appname to root under the application server (changing the application.xml configuration file for the application). This leads to an endpoint like http://server:port/services/FooService which works fine but still has the "services" part on it.
To get rid of the "services" part, i tried:
Changed the "servicePath" property on the axis2.xml configuration file. If I set this property to blank, null, "" or "/" does not work. On the first two cases a "servicePath can't be null or empty" exception is thrown while deploying the application.
Added a new entry on the web.xml file to map the AxisServlet to the url pattern "/", but again it does not work.
So, my question is: Is there any way to get rid of the servicePath parameter?
Supposing there is no way for doing so, another idea is to "redirect" requests from the endpoint url i'm trying to use to the one that axis2 uses (with the servicePath). I'm not sure how to do this, maybe with a servlet? some configuration on the application server?
If you deployed an application as ROOT just put servlet mapping in web.xml :
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>/FooService/*</url-pattern>
</servlet-mapping>