I'm trying to tune a cxf-based webservice. By activating the logging I came across these lines:
2016-05-19 16:33:37,956;DEBUG;org.apache.cxf.phase.PhaseInterceptorChain;Invoking handleMessage on interceptor org.apache.cxf.wsdl.interceptors.WrappedOutInterceptor#384d0499
2016-05-19 16:33:37,956;DEBUG;org.apache.cxf.phase.PhaseInterceptorChain;Invoking handleMessage on interceptor org.apache.cxf.wsdl.interceptors.BareOutInterceptor#78c615ba
2016-05-19 16:33:37,956;DEBUG;org.apache.cxf.ws.addressing.ContextUtils;retrieving MAPs from context property javax.xml.ws.addressing.context.inbound
2016-05-19 16:33:37,957;DEBUG;org.apache.cxf.ws.addressing.ContextUtils;WS-Addressing - failed to retrieve Message Addressing Properties from context
2016-05-19 16:33:37,976;DEBUG;org.apache.cxf.phase.PhaseInterceptorChain;Invoking handleMessage on interceptor org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor#10bed1a8
Between line 4 and 5 it takes 19ms, which is about 20% of the whole request time. So my question is: What causes this gap? And how can I avoid this?
The log says that WS-Addressing is failing. Can I disable WS-Addressing?
Update
I'm using the CXFNonSpringServlet with the following lines to set up the service:
EndpointImpl endpoint = new EndpointImpl(bus, impl);
endpoint.setWsdlLocation("...");
endpoint.setAddress("...");
endpoint.setServiceName(new QName("..."));
endpoint.setEndpointName(new QName("..."));
endpoint.publish();
Related
When I look at the logs in the Google Log Viewer for my GAE project, I see that often the logs that I write myself in the code are assigned to the wrong request. Most of the time the log is assigned to the request directly after the request that produced the log entry.
As the root of every application log in GAE must be a request, this means that the wrong request is sometimes marked as error, because another request before produced an error, but the log is somehow assigned to the request after that.
I don't really do anything special, I use Ktor as my servlet and have an interceptor that creates a log when an exception occurs before returning status 500.
I use Java logging via SLF4J with the google cloud logging handler, but before that I used logback via SLf4J and had the same problem.
The content of the logs itself is also correct, the returned status of the request, the level of the log entry, the message, everything is ok.
I thought that it may be because I use kotlin and switch coroutine contexts during a single request, but in some cases the point where I write the log and where I send the response are exactly next to each other, so I'm not sure if kotlin has anything to do with it.
My logging.properties:
# To use this configuration, add to system properties : -Djava.util.logging.config.file="/path/to/file"
#
.level = INFO
# it is recommended that io.grpc and sun.net logging level is kept at INFO level,
# as both these packages are used by Stackdriver internals and can result in verbose / initialization problems.
io.grpc.netty.level=INFO
sun.net.level=INFO
handlers=com.google.cloud.logging.LoggingHandler
# default : java.log
com.google.cloud.logging.LoggingHandler.log=custom_log
# default : INFO
com.google.cloud.logging.LoggingHandler.level=INFO
# default : ERROR
com.google.cloud.logging.LoggingHandler.flushLevel=WARNING
# default : auto-detected, fallback "global"
#com.google.cloud.logging.LoggingHandler.resourceType=container
# custom formatter
com.google.cloud.logging.LoggingHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=%1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS %4$-6s %2$s %5$s%6$s%n
#optional enhancers (to add additional fields, labels)
#com.google.cloud.logging.LoggingHandler.enhancers=com.example.logging.jul.enhancers.ExampleEnhancer
My logging relevant dependencies:
implementation "org.slf4j:slf4j-jdk14:1.7.30"
implementation "com.google.cloud:google-cloud-logging:1.100.0"
An example logging call:
exception<Throwable> { e ->
logger().error("Error", e)
call.respondText(e.message ?: "", ContentType.Text.Plain, HttpStatusCode.InternalServerError)
}
with logger() being:
import org.slf4j.Logger
import org.slf4j.LoggerFactory
inline fun <reified T : Any> T.logger(): Logger = LoggerFactory.getLogger(T::class.java)
Edit:
An example of the log in Google cloud. The first request has the query parameter GAID=cdda802e-fb9c-47ad-0794d394c913, but as you can see the error log for that request is in the one below, marked in red.
I am using FaspManager as an embedded client in my Java application. My program works fine when I am sending just a single file. When I am trying to send multiple files (each having its own session & jobId) they are starting well and progressing for some time. However, after several minutes when one or two of the transfers complete, rest all of the transfers are stopping without completing.
In the aspera log I can see below messages:
2019-02-11 20:48:22.985 INFO 11120 --- [il.SelectThread] c.c.e.t.aspera.FaspTransferListener : Client session: 149aaa9b-d632-43e4-9653-fbbf768c69b5 | PROGRESS | Rate: 353.6 Kb/s | Target rate: 1.0 Gb/s
2019-02-11 20:48:23.024 INFO 11120 --- [il.SelectThread] com.asperasoft.faspmanager.Session : 149aaa9b-d632-43e4-9653-fbbf768c69b5 - cancel sent
I have not been able to find out who/how a cancel request has been sent. I have tried searching in Google for possible cause but have not been able to resolve it yet. So, I will really appreciate any help on this.
Thank you,
Sourav
The cancel sent message in Session is called if the user specifically calls FaspManager#cancelTransfer(String sessionId), or FaspManager#stop(), or if an error occurs while reading an input stream in FileTransferSession#addSource(StreamReader, String).
I'd guess you're calling stop on the FaspManager after the first session finishes, but I'd need a more complete log, or a snippet of your code to see.
I have a Camel rest endpoint (Jetty) which validates and processes incoming requests. Besides specific Exception handlers (onException) it uses a DLQ error handler (errorHandler(deadLetterChannel...)) which is setup to retry 3 times - if unsuccessful the message is moved to the DLQ.
My question is, how do I still return a user friendly error message back to the client if an unexpected Exception occurs rather than the full Exception body? Is there some config I'm missing on the errorHandler?
I've tried to find some examples on the camel unit tests (DeadLetterChannelHandledExampleTest) and camel in action 2 (Chapter 11) but none seemed to have specific examples for this scenario.
Code is:
.from(ROUTE_URI)
.errorHandler(deadLetterChannel("{{activemq.webhook.dlq.queue}}")
.onPrepareFailure(new FailureProcessor())
.maximumRedeliveries(3)
.redeliveryDelay(1000))
.bean(ParcelProcessor.class, "process");
Thank you for your help!
Use a 2nd route as the DLQ, eg direct:dead and then send the message first to the real DLQ, and then do the message transformation afterwards to return a friendly response.
errorHandler(deadLetterChannel("direct:dead")
from("direct:dead")
.to("{{activemq.webhook.dlq.queue}}")
.transform(constant("Sorry something was wrong"));
when i try to synchronize my caldav server implementation with Thunderbird 45.4.0 and Lightning 4.7.4 (one particular calendar collection) it doesnt show any data or events in the calendar though the last call of the sequence provided the data.
In the Thunderbird error log i can see one error:
Zeitstempel: 07.11.16, 14:21:12
Fehler: [calCachedCalendar] replay action failed: null,
uri=http://127.0.0.1:8003/sap/sports/webdav/appsvc/webdav/services/
server.xsjs/cal/_D043133/, result=2147500037, op=[xpconnect wrapped
calIOperation]
Quelldatei:
file:///Users/d043133/Library/Thunderbird/Profiles/hfbvuk9f.default/
extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-
js/calCachedCalendar.js
Zeile: 327
the call sequence is as follows (detailed content via gist-links):
Propfind Request - Response
Options Request - Response
Propfind Request - Response
Report Request - Response - Response Raw
The synchronization with other clients like macOS-calendar and ios-calendar works in principle and shows the data. Does anyone has a clue what is going wrong here?
Not sure whether that is the cause but I can see two incorrect things:
a) Your <href/> property has trailing spaces:
<d:href>/sap/sports/webdav/appsvc/webdav/services/server.xsjs/cal/_D043133/EVENT%3A070768ba5dd78ff15458f1985cdaabb1.ics
</d:href>
b) your ORGANIZER property is not a valid URI
ORGANIZER:_D043133
i was able to find the cause of the above issue by debugging Thunderbird as propsed by Philipp. The Report Response has http status code 200, but as it is a multistatus response Thunderbird/Lightning expects status code 207 ;-)
Thanks for the hints!
I use breeze.angular to communicate with an olingo OData provider. After changing properties of an Entity I have a pending change. The corresponding object is visible when manager.getChanges() is called.
Calling manager.saveChanges in fact results in successful update of the database through olingo. But simultaneously the following error gets thrown:
TypeError: Cannot read property 'entityAspect' of undefined
at http://localhost:63342/js/breeze.debug.js:14471:38
at http://localhost:63342js/breeze.debug.js:258:26
at Array.map (native)
at __map (http://localhost:63342js/breeze.debug.js:257:15)
at proto.visitAndMerge (http://localhost:63342/js/breeze.debug.js:14470:16)
at http://localhost:63342/js/breeze.debug.js:13102:48
at __using (http://localhost:63342/js/breeze.debug.js:423:16)
at Object.processSavedEntities (http://localhost:63342/js/breeze.debug.js:13091:13)
at saveSuccess (http://localhost:63342/js/breeze.debug.js:13070:67)
at wrappedCallback (http://localhost:63342/js/angular.js:11319:81)
Apparently breeze is unable to change the entityState, as the objects remain pending changes.
Regarding the http communication I observed two Server requests:
Request Method:OPTIONS
Status Code:200 OK
and
Request Method:POST
Status Code:202 Accepted
Why is breeze unable to transact this succesful update?
UPDATE:
Added saveChanges code.
(I removed my own logging methods off the callbacks.)
manager.saveChanges()
.then(saveSucceeded)
.catch(saveFailed)
.finally(saveFinal);
function saveSucceeded(saveResult) {
console.log(saveResult);
}
function saveFinal(saveFinal){
console.log(saveFinal);
}
function saveFailed(error){
console.log(error);
}
saveFailed receives the TypeError above, while saveFinal is undefined.
result object:
{
"d":{
"__metadata":{
"id":"http://localhost:8080/targit2/targit2.svc/Applicationlocations(applicationID=2332,locationID=6)",
"uri":"http://localhost:8080/targit2/targit2.svc/Applicationlocations(applicationID=2332,locationID=6)",
"type":"targit2.Applicationlocation"
},
"applicationID":2332,
"locationID":6
}
}
Breeze uses datajs to convert data to and from the OData formats. I suspect that datajs is having trouble coping with the response from Olingo.
I think Olingo originated with SAP, and this SO post describes a problem with that server.