I'm starting weblogic server in cygwin,
I've added set DEBUG_OPTS = -Xdebug -Xrunjdwp:transport=dt_socket,address=5152,server=y,suspend=y in startwls.sh file
and passed this DEBUG_OPTS when stating the weblogic server.
But the server does not stops to listen the port, I believe there is no effect of debug_opts.
Please help me out to figure this issue.
I'm researching this issue for past two days but no improvement.
First. When you start up the server you should take note that the DEBUG_OPTS that you are setting are being picked up. I don't believe DEBUG_OPTS is supported by the weblogic scripts.
But are you calling export DEBUG_OPTS in your shell script?
In ALSB 2.6 you should take a look at bin/setDomainEnv.sh. The default debug port is 8453 and debug settings will be used if you have debugFlag set to true. See line 300. You could also edit setDomainEnv.sh and put your settings in JAVA_DEBUG on line 297.
OSB works the same but the line numbers in setDomainEnv.sh are different (i.e 411 and 414).
Related
We are attempting to use websockets in ColdFusion (2018.0.13.329786) in an app we have running on Azure VMs behind Cloudflare. However, we are continually getting this error on the client side:
WebSocket connection to 'wss://www.*************.com/cfws' failed:
CFWebSocketWrapper.open # cfwebsocketCore.js:21
init # cfwebsocketChannel.js:49
_cf_websockets_init_6539553945348401 # strategies-for-devel…ing-with-impact:175
fire # cfajax.js:1214
$E.windowLoadHandler # cfajax.js:1321
Uncaught TypeError: Cannot set properties of undefined (setting 'readyState')
at WebSocket.wsConnection.onerror (cfwebsocketCore.js:54:29)
wsConnection.onerror # cfwebsocketCore.js:54
error (async)
CFWebSocketWrapper.open # cfwebsocketCore.js:53
init # cfwebsocketChannel.js:49
_cf_websockets_init_6539553945348401 # *************:175
fire # cfajax.js:1214
$E.windowLoadHandler # cfajax.js:1321
load (async)
$E.onWindowLoad # cfajax.js:1297
cfinit # cfajax.js:1332
(anonymous) # cfajax.js:1834
We have a cfc that's called when a message is posted to a channel that writes to a log file on the server, and this log file never gets updated. This is unsurprising as it appears that something is preventing the connection altogether.
From a configuration perspective, we run these updates when the VM is created:
webSocketObj= createObject("component","cfide.adminapi.websocket");
webSocketObj.setProperty(propertyName="EnableWebSocketServer", propertyValue="true");
webSocketObj.setProperty(propertyName="EnableProxyPort", propertyValue="8581");
and then via cfExecute:
#server.coldfusion.rootdir#/lib/wsproxyconfig.jar -ws IIS -site All -host localhost -port 8581
and then the CF service and IIS are restarted.
We have also enabled the websocket 'switch' in Cloudflare.
This should be the same as going into CF Admin, going to the websockets tab, and then ticking "Use Proxy", and then using the default port of 8581. This should send everything through IIS on port 443 from the client perspective.
Cloudflare and Azure say that no special configuration is needed. And we can see that CF has port 8581 open.
The most infuriating thing is that we worked on this in our Dev environment last year and after much trial and error got it working. However, our notes from that time were not good and when we did the above to try to get this working in our QA environment it did not work. We're obviously missing a step somewhere, but have not been able to figure it out.
Can anyone who has gotten this working explain what steps are required to make ColdFusion websockets work on an Azure VM behind Cloudflare?
We solved this issue. Hopefully this will help anyone else who runs into the same problem:
Per this doc, we realized that the wsproxyconfig was supposed to be creating an 'application' (like a virtual folder) in IIS called cfws pointing to <CF_INSTALL_HOME>/config/wsproxy/1. However, it was not doing so. Once that application was created, everything started working as expected.
Upon further testing we found that it created this application only if it was run as administrator. Otherwise, it reported success and provided no warnings or failures, but did not create the application.
We were running wsproxyconfig from the command line via CFExecute, so it was running under an administrative user, but that was apparently not sufficient. So we moved the wsproxyconfig call to one of our PowerShell scripts and had it run with administrative privileges and that solved our problem.
This had apparently worked in our dev environment originally because we ran wsproxyconfig manually.
Environment:
Windows 10 > Linux (Ubuntu Server) via LAN
PhpStorm
Followed https://xdebug.org/wizard.php
and https://www.jetbrains.com/help/phpstorm/zero-configuration-debugging.html
php.ini (/etc/php/7.2/fpm/php.ini as using Nginx) has:
zend_extension = /usr/lib/php/20170718/xdebug.so
xdebug.remote_enable = On
xdebug.remote.connect_back = 1
;xdebug.remote_host=192.168.56.1;commented out as copied from another PC with VBox (x-debug working here) but left for reference
xdebug.remote_port=24680;port 9000 is usually occupied by FPM, so port change recommended
xdebug.remote_autostart=1
xdebug.idekey=PHPSTORM
xdebug.remote_log="/tmp/xdebug.log"
* EDIT- using xdebug.remote_host=192.168.0.201 works but I want to use multiple network locations to debug from preferablly also WAN *
I have setup bookmarklets as per PhpStorm link and clicked the bookmarklet:
javascript:(/** #version 0.5.2 */function() {document.cookie='XDEBUG_SESSION='+'PHPSTORM'+';path=/;';})()
In the actual IDE the View>debug window is greyed out but allow incoming connections all green. The Language>PHP>Debug is set to stop at first line and has same port number 24680.
In setups on other systems I have at least had flagged up that mappings need attention but I simply cannot get to any debug view here.
tail -f /tmp/xdebug.log
gives:
Log opened at 2018-08-24 21:52:05
I: Connecting to configured address/port: localhost:24680.
W: Creating socket for 'localhost:24680', poll success, but error: Operation now in progress (29).
W: Creating socket for 'localhost:24680', poll success, but error: Operation now in progress (29).
E: Could not connect to client. :-(
Log closed at 2018-08-24 21:52:05
Showing response.
Obviously something missed with connecting back to Windows client PhpStorm.
Tested with Windows firewall off
I will also need to connect remotely via port forwarding to this server at some point, however all this initial setup is on LAN.
When I mention setups regarding other systems they are physically seperate (IE Macbook talking to its own VBox). This setup is a windows machine talking to a real Linux server on the same LAN. SSH is not used here.
php.ini is (/etc/php/7.2/fpm/php.ini as using Nginx)
Anyone got any idea ?
I have developed a portal page using Liferay and the port number is 8080. I wanted to test SSO, I decided not to try with the existing one as there might be some problems and I might end up crashing the whole thing. As a result I downloaded a new liferay portal. Iadded it to the eclipse and ran the second server whose port number was changed to 8085. But the webpage displayed when the second server ran was still 8080 and the same page as the first portal. Later I downloaded the enterprise edition and did the same, still 8080: 1st portal. I changed the plugins, no progress. Later, I changed the port number of first one to 8090. The page was not being displayed at all. Why is it like this? I don't get it. Does liferay work with a single port or can't there be two Liferay portal at a time?
You can always navigate to exactly the port that you configure - given that the appserver actually serves connections to the port. Common mistakes that I see (assuming you're running tomcat):
People change server.xml to refer 8080 to 8090, but leave the other ports (8005 and 8009) untouched. This means that there are conflicts with two tomcats. If you run both tomcats at the same time, the second one will not start, because another program is already listening to 8005 and/or 8009). You'll need to change all ports to unique values (search server.xml for all declarations of port=
You're relying on the browser to automatically open. Liferay's portal-ext.properties allows to override the page to automatically open - either to being empty or to a specific other URL. Configure browser.launcher.url to your requirements (see below)
There might be other servers running on either port that you're trying to have tomcat - or any other appserver - listening on.
(Here's the default for browser.launcher.url)
# Enter a URL to automatically launch a browser to that URL when the portal
# has fully initialized. Enter a blank URL to disable this feature.
#
browser.launcher.url=http://localhost:8080
I'm using GPE (GWT 2.5 plugin) on Eclipse Juno and it looks like the content of the arguments tab gets overwritten each time I perform the apply button. Only workaround is to edit the arguments tab last and then close the dialog. I have to set a different port number, but the port attribute gets deleted as mentioned above. I don't use embedded server.
TIA
ujbi
What port number are you setting? If you're setting it to the default port number expected for that server, it will be removed from the Arguments tab.
Have you tried changing the port number in the Launch Config UI? There should be a tab for "Server", where you can change the port.
#Rajeev
I dont't use the default port (8888) and I dont' want to use the embedded server, so this is not checked in the 'server' tab. The application is running on a JBoss Server on port 8080.
When I add this via '-port 8080' in the 'Arguments' tab it will be romved mostly.
I am running teamcity on Linux server, and it was working completely fine. Once I reboot the server machine and it stopped working. I managed to start the teamcity server using runAll.sh command, but the build agent stays in "disconnected" state. The inactivity reason is being shown as 'server shutdown'. I tried to start the agent using 'agent.sh stop' and 'agent.sh start' but it does not seem to work. Could not get anything meaningful from the logs.
Kindly help.
Thanks
Incase, if you modified the teamcity port then you'll need to change the build agent configuration files to reflect the new serverUrl value. You can find this setting in the C:\TeamCity\buildAgent\conf\buildAgent.properties file.
On the machine that restarted, make sure the firewall didn't come back up in a state that blocks access to/from the agent.
When you restart the agent, the teamcity-agent.log file should have a line saying something like, "buildServer.AGENT.registration - Registering on server". If it succeeds, it should say something like "buildServer.AGENT.registration - Registered: id:.., authorizationToken:..".
Just found this while looking thru my unanswered questions, It was actually a permission issue. I wasn't running the commands as root user. Once I ran 'agent.sh stop' and 'agent.sh start' as a root user, it worked okay.