blazeds push message not working when tomcat is fronted by apache server (though the rpc works) - apache

When using blazeds with apache tomcat, the rpc calls and push messaging system work. But when apache server is placed in front of apache tomcat, only the rpc calls work, the blazeds push messaging does not work. Hope someone has a fix to this and i would be glad if such person is willing to share his/her configuration set-up that worked.
Thanks in advance

Had exactly the same problem too and here is the gist. You are probably using the SteamingAmf. The Apache Server doesnt want you leaving a perpetual open connection to the underlying server and as such buffers your data.
To make everything work you will have to use the polling version. here is a smaple of the configuration you need to do in your services-config.xml
<channel-definition id="my-polling-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
<properties>
<polling-enabled>true</polling-enabled>
<polling-interval-millis>0</polling-interval-millis>
<wait-interval-millis>60000</wait-interval-millis>
<client-wait-interval-millis>3000</client-wait-interval-millis>
<max-waiting-poll-requests>100</max-waiting-poll-requests>
</properties>
</channel-definition>
For the above configuration I am using https.
Configure your messaging-config.xml as follows
<destination id="DestinationID">
<channels>
<channel ref="my-polling-amf"/>
</channels>
<adapter ref="DestinationAdapter"/>
</destination>
This should work assuming that your original setup was working. Good luck.

Related

JIRA Issue/Filter Macro in Confluence generates invalid link

The setup:
Ubuntu 16.04
JIRA Software 7.03 (on port 8080)
Confluence 6.03 (on port 8090)
NGINX 1.10.0 as a reverse proxy to...
Apache 2.4.18
The problem: Whenever I try to embed a JIRA issue into a Confluence page via the built-in JIRA Issue/Filter macro, the issue is successfully located and its status is successfully listed. However, the link from the Confluence page to the actual issue in JIRA points to localhost:8080.
As per the suggestion in Incorrect Links in JIRA Issues Macro (cause #1), I tried enabling ProxyPreserveHost in Apache, with no discernible effect.
Question 1: Am I even digging in the right direction, or is there some other likely cause for the issue that I'm missing?
Question 2: If the issue really is likely due to a configuration mismatch between Confluence and the web server, where should I start digging, given that I'm using NGINX as a reverse proxy?
I'm very hazy on the specifics of configuring web servers. Do I need to verify my settings in both NGINX and Apache, or just Apache (NGINX is set to pass through pretty much everything non-static)? Do I just follow the instructions for Proxying Atlassian server applications with Apache HTTP Server (mod_proxy_http)?
I haven't done this yet because I'm worried my lack of understanding will cause something to explosively decompress.
Thanks in advance!
Since you redirect to localhost:8080 and 8080 is JIRA's default port, I believe that you need to check following and most likely it's related to misconfiguration of the proxy:
Configuration of JIRA Base URL - Is it configured properly?
Do you have proxyPort and proxyName in the connector of server.xml?
What you are seeing when you navigate to Application Link configuration of JIRA and Confluence? Is is showing any errors?

Disable direct access to application via Tomcat

I have a small local (internal to organisation) browser application running on Tomcat. I have inherited an application (also for internal organisation use only) running under PHP server which I have been asked to get running on the same box. I decided the best thing was to get both Tomcat and PHP running under Apache Web Server. Initially I thought this was essential although I now thing as long as I had left them running with different ports this was unnecessary (?).
I have got my Tomcat app running through Apache using the proxy_http_module. I was wondering if there is an easy way to stop direct access to the application via tomcat?
So for example in Tomcat the app is set to run as
http://localserver:1234/superapp
using the virtual host configuration apache allows access as
http://localserver/superapp
presumably this means if I now go in as http://localserver:1234/superapp I am bypassing apache web server ? Assuming (bold assumption) that I have not misunderstood the mechanism, is there a simple way to stop access directly via tomcat (http://localserver:1234/superapp).
Thanks.
You could consider using the proxy_ajp instead of proxy_http. But you can also use the RemoteAddrValve to define restrictions based on IP address:
<Engine name="Catalina" defaultHost="localhost">
...
...
...
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.0\.0\.1"/>
...
</Engine>

axis2 service list page is not loading but WSDL is accessible

I have web services running on Axis2 1.6 within JBoss AS 6.1 as WAR.
Suddenly
http://xxx.xx.xxx.xx:8080/axis2/services/listServices
fails to load in browser.
But,
http://xxx.xx.xxx.xx:8080/axis2/services/MyWebService?wsdl
loads as before.
I have two types of clients to the services.
One Android, the other .NET.
The former works fine, but the latter is not responding.
They all worked until yesterday.
I can't grasp what's going on.
Has anyone had the symptom like this?
<parameter name="hostname" locked="true">MY IP ADDRESS</parameter>
This can happen when you give wrong ip address at (MY IP ADDRESS).

Azure Service Bus over http behind proxy

Microsoft has released the new version of service bus 1.8 last week. I am wondering wheter they have fixed the below issue disscussed in previous post.
http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/a7c78246-9d76-482a-b683-fc4a1e27df59
Publish to Azure Service Bus over http behind proxy
I have tested on latest release and seems the issue is still exits.
Could not connect to net.tcp://abc.servicebus.windows.net:9354/. The connection attempt lasted for a time span of 00:00:21.0500000. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 65.52.160.127:9354
Can anyone please guide me on this.
Thanks.
We have made improvements here with SDK 1.8, specifically for older proxies. Please set the ConnectivityMode to AutoDetect for ServiceBus client and give it a try.
I solved this problem by setting ConnectivityMode to Http and specifying the proxy I want to use in app.config. It is a global state for the application, but it worked for my scenarios so maybe it is helpful here also. http://msdn.microsoft.com/en-us/library/kd3cf2ex.aspx
In my scenario the configuration was to ignore the proxy:
<system.net>
<defaultProxy>
<proxy usesystemdefault="False" />
</defaultProxy>
</system.net>

Why do some setups front-end Glassfish with Apache?

I've been trying to mug up on Glassfish and one thing that keeps coming up is the "how-to" on fronting Glassfish with Apache. Unfortunately, I have yet to find a description of why you would want to do this!
From my experimentation, Glassfish seems like a pretty fully featured web server-type service; but I might be missing a lot. So, is the notion of front-ending Glassfish more of a solution to integrate it with an existing architecture, or does front-ending (in a pure Java environment) provide extra benefits?
There's also another valid use case as to why we front Glassfish with Apache. Apache in this instance would function as a reverse proxy for increased security of your Glassfish. The RP is configured to allow only certain URLs to be passed through to the application server. For e.g., you may have app contexts /myApp and /myPrivApp deployed in Glassfish. In the RP server, you only configure /myApp to be passed to Glassfish. Anybody requesting for /myPrivApp would see a 404 'cos the request stops right at the RP level.
In one of my deployments, I have a bunch of WARs deployed, some for users coming from the internet, some for intranet only. I have 2 RPs running, one for internet users and the other for intranet. I configure the internet RP to only allow URLs for approved internet applications to pass through while intranet users get to see everything.
Hope that helps.
It is usually used to speed things up. Since apache is a very fast web server it is used to deliver static content. Like images, CSS files and so on. Glassfish serves the dynamic content (servlets, JSPs) in this scenario.
Another reason for using Apache as a frontend to Glassfish is the possibility to provide load balancing across a Glassfish cluster. See http://tiainen.sertik.net/2011/03/load-balancing-with-glassfish-31-and.html for details.
A other reason is that glassfish cannot run (easily) on port 80, without giving it root rights of course.
So, for most users it's easer to run a proxy (apache, nginx, varnish) some sort in front of apache and have both servers run under a normal user.
Then you have a other advantage of some configurations options of your front end. Like others mentioned, caching for example.