I'm trying to get an Azure Servicebus WCF relay to work following this tutorial:
https://learn.microsoft.com/en-us/azure/service-bus-relay/service-bus-relay-tutorial
While following the steps I ran into this exception: System.ServiceModel.AddressAlreadyInUseException
In this case the exception message was "This endpoint requires IsDynamic = False". That I could fix by explicitly setting this property to false.
After this fix still the same AddressAlreadyInUseException
However the message now changed to "Address sb://[namespace].servicebus.windows.net/[WCF Relay name] is already in use by an existing listener with different settings"
I really can't understand where this error comes from, as it's a newly created WCF Relay endpoint and no other listeners are running. What could be causing this?
Are you creating a WCF Relay explicitly in the portal (or with NamespaceManager.CreateRelay[Async]) for this endpoint? If so, then you need the binding's IsDynamic == false). If you're not pre-creating the endpoint then the binding's IsDynamic must be true.
Are you using NetTcpRelayBinding or some other relay binding?
If you try again after ~30 minutes do you get the same errors?
If you try with a different WCF Relay(endpoint) address do you see the same behavior?
We just had this happen for a really strange reason so am posting here in case it helps anyone else.
Someone configured a tenant with a service path of ./. This made it so the root path was taken and then every tenant that tried to register would get the error "Address sb://[namespace].servicebus.windows.net/[WCF Relay name] is already in use by an existing listener with different settings". When we turned off the bad endpoint all the other endpoint were able to work again.
Related
I have a WCF name pipe service, to communicate 2 processes on windows.
I've tested it on my machine and it worked, I've developed an installer for it, and it's working for most users, but some users are getting a TimeoutException with this message:
"request operation sent to net.pipe://localhost/myService did not receive a reply within the configured timeout (00:00:10). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client."
What can be the reason for this error? Is it a security issue? Where can I set security settings for named pipes?
Thanks
Some users may not receive a reply in time due to network problems, which may cause a timeout.
You can configure the timeout setting in configuration file by setting the send and receive timeout on binding element.
Apply the binding configuration on both service and client-side:
<netNamedPipeBinding>
<binding sendTimeout="00:20:00" receiveTimeout="00:20:00">
<reliableSession inactivityTimeout="00:20:00"/>
</binding>
</netNamedPipeBinding>
INFO [main] org.apache.nifi.bootstrap.Command Apache NiFi is currently running, listening to Bootstrap on port 20740, PID=31405
That means NiFi is running, and I can see its log in logs/nifi-app.log.
The UI is available at https://servername:9443/nifi. It successfully initiated communication with Bootstrap.
But i have this error, and the UI fails to appear. Do you have any solutions?
Failed to invoke #OnEnabled method of JettyWebSocketServer[id=01591009-1d2b-177f-e304-a7cc87d735ce] due to java.net.BindException: Address already in use
"java.net.BindException: Address already in use" means a port is already in use by something else on your system.
In this case it shows that it is coming from the JettyWebSocketServer controller service which is trying to bind to port 9998.
You can use "netstat -lntp" to see what is using port 9998. It could also be possible that you have more than one instance of the controller service with both of them configured with port 9998 and one of them is binging to it and the other fails.
Seems like a Controller Service that fails... Try browsing your flow.xml.gz and check for any ControllerServices named JettyWebSocketServer. Change their <state></state> from <state>ENABLED</state> to <state>DISABLED</state> and try running NiFi again.
You can tell it is a controller service by the #enabledannotation which invokes a method that needs to run when the controller service is enabled.
NiFi shouldn't fail to start because of a failing controller service but it seems to be the problem(probably a bug).
After it start back up, you can configure the controller service to run on a different port.
I also suggest, that if it is the case, that you open an issue to Apache about this since it seems like a pretty major bug.
As described in the header I want to use remote services in an OSGI environment. So I decided to handle this with eclipse ECF. In my opinion a very good project to deal with OSGI remote services. So for the discovery provider I use Zoodiscovery. The services are registered with generic service property. Furthermore, Zoodiscovery is used in centralized mode and the central IP is published with a network broadcast. I got everything to work. But after a period of time the service consumer loses the remote service.
This message is shown when the remote service is discovered:
[log;+0000 2016.04.22 15:26:03:564;DEBUG;org.eclipse.ecf.provider.zookeeper;Service Discovered: ServiceInfo[uri=ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=;id=ServiceID[type=ServiceTypeID[typeName=_ecfosgirsvc._default.default._iana];location=ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=;full=_ecfosgirsvc._default.default._iana#ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=];priority=0;weight=0;props=ServiceProperties[{objectClass=de.custom.service.api.IManagerService, endpoint.id=e9dc7ac1-708d-43a6-b2fa-539beff6c732, remote.intents.supported=passByValue exactlyOnce ordered, ecf.endpoint.id=ecftcp://192.168.178.21:2121/server, ecf.rsvc.id=3, endpoint.service.id=174, service.imported.configs=ecf.generic.server, ecf.endpoint.ts=1461329304080, ecf.generic.server.hostname=192.168.178.21, ecf.endpoint.id.ns=org.eclipse.ecf.core.identity.StringID, remote.configs.supported=ecf.generic.server, endpoint.package.version.de.custom.api=1.0.0, endpoint.framework.uuid=70eaf65a-8608-0016-13af-dcea8562a726}]]]
This message is shown when the remote service is undiscovered:
[log;+0000 2016.04.22 15:28:53:125;DEBUG;org.eclipse.ecf.provider.zookeeper;Service Undiscovered: ServiceInfo[uri=ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=;id=ServiceID[type=ServiceTypeID[typeName=_ecfosgirsvc._default.default._iana];location=ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=;full=_ecfosgirsvc._default.default._iana#ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=];priority=0;weight=0;props=ServiceProperties[{objectClass=de.custom.service.api.IManagerService, endpoint.id=e9dc7ac1-708d-43a6-b2fa-539beff6c732, remote.intents.supported=passByValue exactlyOnce ordered, ecf.endpoint.id=ecftcp://192.168.178.21:2121/server, ecf.rsvc.id=3, endpoint.service.id=174, service.imported.configs=ecf.generic.server, ecf.endpoint.ts=1461329304080, ecf.generic.server.hostname=192.168.178.21, ecf.endpoint.id.ns=org.eclipse.ecf.core.identity.StringID, remote.configs.supported=ecf.generic.server, endpoint.package.version.de.custom.api=1.0.0, endpoint.framework.uuid=70eaf65a-8608-0016-13af-dcea8562a726}]]]
BUT: On host system everything is fine and the service is online. If I restart the OSGI framework on consumer side everything works fine again until this Undiscovery event. The period of time between discovery and undiscovery is equal of length.
It seems as if there is a timeout undiscovering the service. If I use the service by calling a method there is no different behaviour.
Has anyone an idea what’s going on?
Thank you for help and best regards!
UPDATE:
Ok one update:
When the remote service is discovered I fetched it in a local parameter on client side. When the remote service is unpublished on client side (NOT on server side, as described in my previous post) I can call methods from the fetched instance. So the proxy is still available and it is working fine until I unpublish the remote service on server side. So the proxy is unpublished only in OSGI service registry.
Best regards!
We are attempting to connect to a WebDAV server using net use over SSL. On some servers we're seeing an issue in which this connection only succeeds if we specify port 443 in the URL.
Does Map
net use * "https://example.com:443/folder"
net use * "\\example.com#SSL#443\folder"
and, bizarrely, so does this:
net use * "\\example.com#SSLasdf\folder"
Does Not Map
net use * "https://example.com/folder"
net use * "\\example.com#SSL\folder"
In the non-working cases we consistently receive the following error:
System error 67 has occured.
The network name cannot be found.
We have noticed some things that might be useful information:
We have a test server that's configured the same way as the prod server and it works as expected.
In the non-working cases, no incoming requests are ever seen at the prod server from the failing host.
All clients are based on the same image.
The problem does not manifest uniformly on all clients -- some work, some don't.
There is an existing, valid entry for example.com in the client DNS cache.
Flushing the client DNS cache of the affected servers does not resolve the problem.
Once the problem appears, it seems to stick. That is, if I execute one of the working mappings, delete it, and then immediately execute one of the non-working mappings, the problem persists.
We are utterly stumped. Any theories?
You are seeing different behaviors because you are connecting using different names. Once a name has been attempted and failed, the WebClient (this is the service that enables WebDAV) will cache the response for a period. To clear the cache, locate the WebClient service in the Services console and restart it. Or from an administrative command prompt execute the following command:
net.exe stop webclient && net.exe start webclient
We ultimately determined that we were mis-interpreting the System Error 67 that net use was returning. We discovered two interesting things:
In the event that the WebDAV returns a 404 or a 50x on the initial, root folder PROPFIND, net use will (rightly) interpret this as the root folder being unavailable. The fact that it says the network name could not be found let us to believe that the problem was with the name resolution, but it was really just saying, 'hey, I couldn't find anything at this path.'
If 'net use' fails due to a 404/50x, it appears that for a brief period of time it will automatically fail any additional mappings for that same host without issuing a request. For example, if net use http://me.com/foo returns a 404, then net use http://me.com/bar will instantly fail if made in rapid succession to that first call, and no request record will be seen in the WebDAV server logs.
My best guess is that appending the #443 port didn't make any real difference. What it perhaps did do was to trick net use into thinking it was talking to a different host, at least for the purposes of its 'auto-fail' feature. But that's just a guess.
I am trying to connect to Websphere MQ 7.1 with Hermes JMS but I am not able to. I have followed their giude, loaded all the jars without problems, set the plugin, set all the variables (hostname, port, transportType, queuemanager), checked the box at the bottom that says user and typed the username and password and after confirming I tried to discover however I get the following message back:
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.
at
com.ibm.mq.MQManagedConnectionJ11.(MQManagedConnectionJ11.java:233)
at
com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553) at
com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at
com.ibm.mq.StoredManagedConnection.(StoredManagedConnection.java:95)
at
com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at
com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:882)
at
com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:770)
at
com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:719)
at
com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:175)
at com.ibm.mq.MQQueueManager.(MQQueueManager.java:647) at
hermes.ext.mq.MQSeriesAdmin.getQueueManager(MQSeriesAdmin.java:107)
at
hermes.ext.mq.MQSeriesAdmin.discoverDestinationConfigs(MQSeriesAdmin.java:280)
at
hermes.impl.HermesAdminAdapter.discoverDestinationConfigs(HermesAdminAdapter.java:82)
at
hermes.impl.DefaultHermesImpl.discoverDestinationConfigs(DefaultHermesImpl.java:1126)
at
hermes.browser.tasks.DiscoverDestinationsTask.invoke(DiscoverDestinationsTask.java:77)
at hermes.browser.tasks.TaskSupport.run(TaskSupport.java:175) at
hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170) at
java.lang.Thread.run(Thread.java:662)
After a few hours of trial and error and research on the net, it seems that the issue is that it cannot connect due to bad authorization however I am able to connect using Java code (Using same lib MQQueueConnectionFactory) and I am also able to connect using QueueZee with the exact same libraries, get a list of all queues and browse them so I know user authorization issues should not be the problem.
I am running Hermes JMS 1.14 and I tried using both Java 1.6.0_33 and 1.7.0_5. Websphere MQ is running on version 7.1.0.0 and the libraries were gotten from this installation on a remote server.
I tried setting the channel variable to SYSTEM.DEF.SVRCONN which is what I used in QueueZee to get it to work but still the same issue.
Has anybody seen this issue before and hopefully can shed some light in the situation?
At V7.1 the new CHLAUTH rules shut off access to all SYSTEM.* channels except SYSTEM.ADMIN.SVRCONN by default and do not allow any administrative access on any SVRCONN channel by default. In order to diagnose this it would be necessary to know what channel was used, the CHLAUTH rules that are set, the channel definition (in particular, the MCAUSER value) and whether the ID used is in the mqm group.
You didn't mention whether the QueueZee setup was also to a V7.1 QMgr or this one in particular. Taking a wild guess, I'd say that CHLAUTH rules are enabled and that the SYSTEM.DEF.SVRCONN channel is disabled at this point. Recommended steps are to define a new channel whose name doesn't start with SYSTEM. and make sure the ID used is not in the mqm group but is authorized as a non-admin ID.
Alternatively, an ID in the mqm group can be used but you'd have to define a CHLAUTH rule to allow it to work. For example, the default CHLAUTH rule uses CHANNEL(*) BLOCKUSER(*MQADMIN) and you could change that to CHANNEL(THE.NEW.CHL.NAME) BLOCKUSER('nobody'). The new rule would be more specific than the old rule and thus take precedence on your channel. It tells the QMgr to block the user ID 'nobody' but omits any mention of *MQADMIN. Since 'nobody' doesn't have access anyway but since *MQADMIN is not mentioned (and thus not blocked by thei rule) the effect of the rule is to allow admins on this channel.
As a quick, dirty and temporary measure, you can also ALTER QMGR CHLAUTH(DISABLED) to get the same behavior as in v7.0 and earlier QMgrs. Be aware though that this allows anonymous remote admin and remote code execution using the mqm user ID. That's why the default settings were changed. Now you must explicitly provision remote admin access if you need it.
For more on this topic, I recommend the Securing Your QMgr presentation from the IMPACT conference.
Note that the password the app sends in is not checked by the QMgr. The field exists so that channel exits can validate the password against AD, LDAP, etc. Without such an exit, the password is ignored. The user ID passed in by the client is either accepted at face value or modified by the channel's MCAUSER or by CHLAUTH rules.
Finally, when having authorization problems the easiest way to diagnose is to ALTER QMGR AUTHOREV(ENABLED) and then use SupportPac MS0P to decode the PCF messages in WMQ Explorer. The auths errors end up in the QMgr Event queue. Each message tells you the object that failed auths, the API call made against that object, the options of the call and the ID that made the call. Often we find the ID making the call isn't the one we wanted or that the program is using options it isn't authorized for so this can be extremely helpful.
Not really an answer, just a little research on the problem.
I have faced the same problem about hour ago. I am passing the username like domain\sortoflongusername and what i see in systemlog on WSMQ server is that my username is being truncated to 12 symbols.
I'm not really familiar with hermesJMS and soapui at all (just wanted to offer it to our testers to check it out as testing platform), so maybe anyone here does know about roots of this problem.