We are using Websphere with her JAX-RS implementation. Our app reuse Client object (does not close it after every call). But in IBM JAXRSClientImpl is some baseClients hashMap (cxf use WeakHashMap) with is still growing. I didnt find other solution how to fix this except close the Client object. Any sugestions?
The previously posted assumption is correct that the use of a HashMap for client references was causing these refs to hang around until the client was closed, causing a potential memory leak. The code in com.ibm.ws.jaxrs20.client.JAXRSClientImpl has been fixed to utilize a WeakHashMap, which should address this issue. The change has been delivered under APAR PH28458 (https://www.ibm.com/support/pages/apar/PH28458). The fix for this APAR is targeted for inclusion in fix pack 9.0.5.6.. So if you upgrade to version 9.0.5.6 or newer the issue should be resolved.
Related
I am facing a weird problem today, when running my MuleSoft application locally from my AnypointStudio and firing a request from postman, I am getting 403 error. When debugging I found out that the application is checking for flowVars._clientName, however it is missing. According to this documentation, actually yes flowVars._clientName is expected.
https://help.mulesoft.com/s/article/How-to-get-the-client-application-name-in-a-flow-based-on-the-client-id-and-client-secret.
So my application fails with 403 error. Seems that other environments are working perfectly fine.
And yes it is using Client Id enforcement.
Any clues?
Without more details it looks like the issue is inside the logic of your application. The KB article that you referenced is a how to in case you need to obtain the client name. It doesn't say that you have to use for authentication. You don't describe how the application does authentication/authorization. Is it in a flow? Or in a policy? If it is the standard Client ID enforcement policy, the expressions to evaluate client id and secret can be configured, but I don't think the default is not #[flowVars._clientName] nor #[flowVars._clientId].
Note that Exchange is basically a repository of APIs and other artifacts. It doesn't authenticate anything at execution time. Unless your application is trying to use it somehow, but I can't think of a reason for that.
The issue was resolved only by re-downloading Anypoint Studio and mule runtime. Very weird, it was happening only for one application, not for the others. Creating a new workspace did not help, deleting the application and re-cloning and installing did not help, even recloning in a new directory did not help. Only using a new Anypoint Studio and runtime installation resolved it (even with the old code base) ...
Does anyone know how to configure NServiceBus (v6.2) using the AzureServiceBusTransport to not attempt to create namespaces?
I'd like to configure NServiceBus the use a connection string which only has permissions to send (the queue's should already be there and if not an error is more appropriate than creation) but whenever I configure it this way I get the following error:
Pre start-up check failed: Configured to create topology, but have no manage rights for the following namespace(s): xxxxxxxxxxxxxx
This error message suggests the functionality is configurable but having looked through the code and the documentation for the mechanism I can't find it.
Many thanks
Adam
Looks like I answered my own question - a bug was raised against the AzureServiceBusTransport and subsequently fixed a little while ago:
https://github.com/Particular/NServiceBus.AzureServiceBus/issues/528
As the bug says upgrading to version 7.1.8 or 7.2.3 and not enabling installers fixes the issue.
I got concurrency issue while starting the JVM due to a particular app. Start-up hangs during message driven activation. I got this URL
http://www-01.ibm.com/support/docview.wss?uid=swg1IZ68236 (the same error I got for myself as mentioned in URL) and fixed as a local solution. Want to fix this issue as a permanent solution but got to know the 'ConnectionConcurrency' has been removed from v7+. Can anyone please suggest me how to fix this as a permanent solution.
The permanent solution is as documented in the APAR closing words; that is, a configuration change to set the value of the MQ Resource Adapter property "ConnectionConcurrency" to the value 1 at Cell scope (if using WebSphere Application Server). There is no change code for the WebSphere MQ v7.0.1 RA (shipped in WAS v7.0 or 8.0) for this issue.
Note: It does not matter what scope your Activation Specifications are actually defined at (whether that be Cell, Node or Server), the value of "ConnectionConcurrency" is always taken from the RA defined at Cell scope.
From the WebSphere MQ v7.1 Resource Adapter (shipped in WAS v8.5), the "ConnectionConcurrency" attribute is always set to the value 1 to avoid the deadlock issue described by APAR IZ68236.
I have a problem running a Java (using Metro) client against a .NET STS and secured web service. However, when I run my .NET based client, it always works.
As you probably already know, when a JAX-WS client is ran, it requests metadata from the service during runtime (even though it already has ran wsimport during design time). However, it seems that this runtime metadata request is where my problem is.
The problem that I'm facing is that during the runtime requests of metadata, some WSDL's exported by my WCF service caused the Java client to just 'hang' during the mex requests. When it hangs, it doesn't even get to the point of issuing the RST request.
For example, I can get to a spot where I have 9 [OperationContract] attributes and it works. But when I add a 10th service method, it doesn't work. However, if I remove one of the 9, then it works. I know there isn't a problem with a particular method because I can mix and match and the same pattern holds.
I can't seem to deduce a pattern or reason for why some WSDL's work and some don't. I strongly doubt there is a limit to the number of service methods. However, could this be a problem with "overall complexity" with the exported WSDL?
Does anyone have any ideas? Have anyone run into this issue before?
If more information is needed, I can glady post it. I'm just trying to keep the initial post a manageable length.
I will also add that I'm running the STS and secured web serivce in .NET 4, and they are based on WIF (so I don't have to worry about security settings). My .NET client is also .NET 4. On the Java side, I'm using Netbeans 6.9.1 with Metro 2.1 running Glassfish 3. I've verified that I receive the same issue running on Metro 2.0.
Please see WSDL Requests with Metro/JAX-WS/WSIT During Runtime for a detailed answer.
Following the example given, there're chances that MaxMessageReceivedSize or MaxStringContentLength limit is reached. Have you tried increasing the values of MaxMessageReceivedSize and MaxStringContentLength for binding? You can try enabling WCF traces, there'd be a warning logged if any such limit is reached.
My code is consistently generating the following error:
org.apache.axis2.AxisFault: Timeout waiting for connection
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:203)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:76)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:400)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:225)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:435)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:402)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
After extensive searching the solution appears to be here:
http://amilachinthaka.blogspot.com/2009/05/improving-axis2-client-http-transport.html
Except I cannot access http client directly (that is done in auto generated code).
Instead I have tried:
http://wiki.apache.org/ws/FrontPage/Axis/AxisCommonsHTTP
Which seems to help slightly. However it only delays the problem I always get the timeout. Also the instructions appear to be for an old version of Axis since Axis2 does not have AxisProperties. I am using version 1.5.1. Any suggestions?
I think this was a bug, see here and has been fixed with Axis2 1.5.2 (at least for generated code). With custom code, you need to tackle this problem manually.