I'm using Karate for validation tests.
I setup a retry on one of my request but sometimes there is more than 100 retry, this create to big useless logs with the same big payload on each request...
And this bloat my CI.
I want to reduce this logs quantity, maybe by disable log for just this request ?
I've tried * configure report = false but this disable only on Cucumber html report.
I want to disable also in STDOUT console.
So maybe with some form of log level manipulation setted in the logback-test.xml ?
Thanks.
No you con't disable logs per request, you can switch off everything by setting the log level to INFO - but I guess you don't want that. 100 retries sounds very unusual to me. You can try your luck with a feature request - but I can tell you that this would be low priority unless someone contributes code.
If this really bothers you, write some custom Java code to do this polling + HTTP request and call it from Karate.
EDIT: I think I have a solution that will work for you. You can completely disable the Karate logs appearing on the console - while still having the HTML report with this change to the logback-test.xml:
<root level="warn">
<!-- <appender-ref ref="STDOUT" /> -->
<appender-ref ref="FILE" />
</root>
So just commenting out the console log appender will do the trick !
Also read: https://github.com/intuit/karate#report-verbosity
I want to provide security one way or another for Sending and Getting JSON Data,but I don't know how to do this.
Our System has roles of users (System admin, General Members, etc.)
We decided send data as JSON using the Spring MVC URL pattern. I don't want everybody that outside from system to use this URL, only users can use the URL.
Example
www.example.com/services/"hereUserPass"/"hereUserName"/category/3
Each request time for different URLs, Should I control the username and password whether registered before? or What should I do for Security?
You want to implement security into your Spring Web application. You can do this at two ways:
Url Based Security
Method Based Security
Try to make another xml file as like applicationContext-security.xml Here is an example:
<http use-expressions="true">
<intercept-url pattern="/" access="permitAll"/>
<intercept-url pattern="/static/**" filters="none" />
<intercept-url pattern="/**" access="isAuthenticated()" />
<form-login />
<logout />
</http>
Here we see that permitAll means permit everybody who wants to reach that URL. filters = none has the same effect but it means that user will not go over Spring Security(Previous one goes over Spring Security but has access, filtering doesn't applied). isAuthenticated means that user can reach there if authenticated. You can also apply role based acces to urls.
Other security implementation base on middle tier security. You should add this line at your application context security file:
<global-method-security pre-post-annotations="enabled" />
so you can use method based security as like:
#PreAuthorize("hasRole('ROLE_SUPERVISOR')")
void storeVisit(Visit visit) throws DataAccessException;
You can start to reading with Spring Security implementation of Spring's Pet Clinic example: http://static.springsource.org/spring-security/site/petclinic-tutorial.html
Also I recommend you read here: http://www.mularien.com/blog/2008/07/07/5-minute-guide-to-spring-security/
I wrote a wcf service that uses BasicHttpBinding with some url and a client using this service.
Users should launch a client application and specify the same url that is specified in server endpoint.
However, if a user inadvertently opens this url in a web browser, he/she sees information on how to retrieve service metadata, which is absolutely useless to them.
What should be done in order for him/her to see, for example a help topic?
You need to turn off the publication of the service's metadata.
You can disable it in the Web.config:
<serviceMetadata httpGetEnabled="false" />
You can find more information on MSDN here:
http://msdn.microsoft.com/en-us/library/system.servicemodel.description.servicemetadatabehavior.httpgetenabled.aspx
http://msdn.microsoft.com/en-us/library/ms731317.aspx
Of course this will still generate a default landing page if a user manually enters the service's URL in the address bar (e.g.: http://www.examle.com/service.svc). However now it will mention that the metadata is currently disabled.
If you want to customize that page I'd suggest you check out the following thread, it contains a complete code sample on how to set it up:
http://social.msdn.microsoft.com/forums/en-US/wcf/thread/5778651a-b212-438a-b3e8-f7029775d52a/
If you want to have custom help page instead of default one you need to modify ServiceDebug behavior:
<behaviors>
<serviceBehaviors>
<behavior name="...">
<serviceDebug httpHelpPageEnabled="true" httpHelpPageUrl="Your custom page url" />
</behavior>
</serviceBehaviors>
<behaviors>
The same properties also exist for HTTPS and in case of some special requirements you can also control their "binding".
I am calling a WCF service method repeatedly in a loop (with different params on each iteration) and it is causing timeout after around 40 mins. I am using the same proxy object and closing it only once the loop is completed like this. how can I avoid this timeout error? do I need to instantiate a new proxy for each call. (actually I am calling a SQL server reporting server webservice here and passing different params to generate different reports and I am not using a new proxy for each iteration thinking that could slow down generation of reports). here is the client is also a WCF service and it is hosted in a windows service.
(this is just an example for illustration, not the actual code that is failing)
using(var proxy=new serviceclient())
{
for(var i=0;i<50;i++)
{
proxy.methodName(i);
}
}
The error message is something like this
System.TimeoutException: The request
channel timed out while waiting for a
reply after 00:01:00. Increase the
timeout value passed to the call to
Request or increase the SendTimeout
value on the Binding. The time
allotted to this operation may have
been a portion of a longer timeout.
---> System.TimeoutException: The HTTP request to
'http://localhost/ReportServer/ReportExecution2005.asmx'
has exceeded the allotted timeout of
00:01:00. The time allotted to this
operation may have been a portion of a
longer timeout. --->
System.Net.WebException: The operation
has timed out
here is the client WCF config (only part that is related to the reporting services, not the entire WCF config)
<bindings>
<basicHttpBinding>
<binding name="ReportExecutionServiceSoap" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647"
maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost/ReportServer/ReportExecution2005.asmx"
binding="basicHttpBinding" bindingConfiguration="ReportExecutionServiceSoap"
contract="ReportExecutionServiceReference.ReportExecutionServiceSoap"
name="ReportExecutionServiceSoap" />
</client>
this issue is resolved now. one of the reports (generated by making a call to the report server ASMX webservice) was taking longer than usual and causing the timeout, it was NOT due to the number of calls in the loop (each webservice call is synchronous and not queued up). To resolve this, I used the standard ASP.NET webservice API instead of WCF to call the report execution webservice and set the timeout to infinite like this
var webServiceProxy = new ReportExecutionServiceReference.ReportExecutionService()
{
Url = ConfigurationManager.AppSettings["ReportExecutionServiceUrl"],
Credentials = System.Net.CredentialCache.DefaultCredentials
};
webServiceProxy.Timeout = Timeout.Infinite;
the timeout could have been set to a bigger value instead of infinite as well. this webservice is called in a loop for each report and it takes about two hours to generate all the user selected reports in one go. client is a WCF service and hosted in a windows service instead of IIS to avoid a timeout on the client. thanks for all the replies.
If you are doing asynchronous calls from the client and the server is not a "webfarm" all the calls will be qued on the server. And that could make calls timeout. It doesn't really say fron your code.
Let say that you do are going through a list with 10 items, each response takes 10 seconds to process on the server. Since you are using the same proxy all calls will be quite quick to dispatch from client code. But it will take around 100 seconds to return all answers ( note that i dont take into consideration that you have network latency, object serilization etc etc)
That means that all calls after nr 6 will timeout.
If the server would have more threads available to process data this could ve avoided, but the problem could popup somewhere else. You should be able to try the same call again, since a timeout could accour for any other reason as well, network problem, temporary server overload etc etc.
I would sugest making some sort of quing system that dispatches all the server calls so that you could make the same call again. How that would be implemented depends on your scenario:
Do they need to be sent in a specific order?
Do you need to know when the last call has returned?
etc.
This simply means your server can't deal with the load, or is taking too long for some other reason. Ask the server why it's taking too long; don't be surprised when the client times out.
Dim ws As WCFService.ServiceClient = New WCFService.ServiceClient
ws.Endpoint.Binding.SendTimeout() = TimeSpan.FromSeconds(2)
Is there any way to "subscribe" from GWT to JSON objects stream and listen to incoming events on keep-alive connection, without trying to fetch them all at once? I believe that the buzzword-du-jour for this technology is "Comet".
Let's assume that I have HTTP service which opens keep-alive connection and put JSON objects with incoming stock quotes there in real time:
{"symbol": "AAPL", "bid": "88.84", "ask":"88.86"}
{"symbol": "AAPL", "bid": "88.85", "ask":"88.87"}
{"symbol": "IBM", "bid": "87.48", "ask":"87.49"}
{"symbol": "GOOG", "bid": "305.64", "ask":"305.67"}
...
I need to listen to this events and update GWT components (tables, labels) in realtime. Any ideas how to do it?
There is a GWT Comet Module for StreamHub:
http://code.google.com/p/gwt-comet-streamhub/
StreamHub is a Comet server with a free community edition. There is an example of it in action here.
You'll need to download the StreamHub Comet server and create a new SubscriptionListener, use the StockDemo example as a starting point, then create a new JsonPayload to stream the data:
Payload payload = new JsonPayload("AAPL");
payload.addField("bid", "88.84");
payload.addField("ask", "88.86");
server.publish("AAPL", payload);
...
Download the JAR from the google code site, add it to your GWT projects classpath and add the include to your GWT module:
<inherits name="com.google.gwt.json.JSON" />
<inherits name="com.streamhub.StreamHubGWTAdapter" />
Connect and subscribe from your GWT code:
StreamHubGWTAdapter streamhub = new StreamHubGWTAdapter();
streamhub.connect("http://localhost:7979/");
StreamHubGWTUpdateListener listener = new StockListener();
streamhub.subscribe("AAPL", listener);
streamhub.subscribe("IBM", listener);
streamhub.subscribe("GOOG", listener);
...
Then process the updates how you like in the update listener (also in the GWT code):
public class StockListener implements StreamHubGWTUpdateListener {
public void onUpdate(String topic, JSONObject update) {
String bid = ((JSONString)update.get("bid")).stringValue();
String ask = ((JSONString)update.get("ask")).stringValue();
String symbol = topic;
...
}
}
Don't forget to include streamhub-min.js in your GWT projects main HTML page.
I have used this technique in a couple of projects, though it does have it's problems. I should note that I have only done this specifically through GWT-RPC, but the principle is the same for whatever mechanism you are using to handle data. Depending on what exactly you are doing, there might not be much need to over complicate things.
First off, on the client side, I do not believe that GWT can properly support any sort of streaming data. The connection has to close before the client can actually process the data. What this means from a server-push standpoint is that your client will connect to the server and block until data is available at which point it will return. Whatever code executes on the completed connection should immediately re-open a new connection with the server to wait for more data.
From the server side of things, you simply drop into a wait cycle (the java concurrent package is particularly handy for this with blocks and timeouts), until new data is available. At that point in time, the server can return a package of data down to the client which will update accordingly. There are a bunch of considerations depending on what your data flow is like, but here are a few to think about:
Is a client getting every single update important? If so, then the server needs to cache any potential events between the time the client gets some data and then reconnects.
Are there going to be gobs of updates? If this is the case, it might be wiser to package up a number of updates and push down chunks at a time every several seconds rather than having the client get one update at a time.
The server will likely need a way to detect if a client has gone away to avoid piling up huge amounts of cached packages for that client.
I found there were two problems with the server push approach. With lots of clients, this means lots of open connections on the web server. Depending on the web server in question, this could mean lots of threads being created and held open. The second has to do with the typical browser's limit of 2 requests per domain. If you are able to serve your images, css and other static content fro second level domains, this problem can be mitigated.
there is indeed a cometd-like library for gwt - http://code.google.com/p/gwteventservice/
But i ve not personally used it, so cant really vouch for whether its good or not, but the doco seems quite good. worth a try.
Theres a few other ones i ve seen, like gwt-rocket's cometd library.
Some preliminary ideas for Comet implementation for GWT can be found here... though I wonder whether there is something more mature.
Also, some insight on GWT/Comet integration is available there, using even more cutting-and-bleeding edge technology: "Jetty Continuations". Worth taking a look.
Here you can find a description (with some source samples) of how to do this for IBM WebSphere Application Server. Shouldn't be too different with Jetty or any other Comet-enabled J2EE server. Briefly, the idea is: encode your Java object to JSON string via GWT RPC, then using cometd send it to the client, where it is received by Dojo, which triggers your JSNI code, which calls your widget methods, where you deserialize the object again using GWT RPC. Voila! :)
My experience with this setup is positive, there were no problems with it except for the security questions. It is not really clear how to implement security for comet in this case... Seems that Comet update servlets should have different URLs and then J2EE security can be applied.
The JBoss Errai project has a message bus that provides bi-directional messaging that provides a good alternative to cometd.
We are using Atmosphere Framewrok(http://async-io.org/) for ServerPush/Comet in GWT aplication.
On a client side Framework has GWT integration that is pretty straightforward. On a server side it uses plain Servlet.
We are currently using it in production with 1000+ concurent users in clustered environment. We had some problems on the way that had to be solved by modifying Atmosphere source. Also the documentation is really thin.
Framework is free to use.