[JBoss JIRA] Closed: (JBAS-3219) Error on lookup From a clustered SLSB to another clustered SLSB
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3219?page=all ]
Brian Stansberry closed JBAS-3219.
----------------------------------
Resolution: Rejected
Please reopen if the problem still exists after implementing Darran's suggesting configuration.
> Error on lookup From a clustered SLSB to another clustered SLSB
> ---------------------------------------------------------------
>
> Key: JBAS-3219
> URL: http://jira.jboss.com/jira/browse/JBAS-3219
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Naming
> Affects Versions: JBossAS-4.0.3 SP1
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.0.5.CR1
>
>
> Hello,
> My situation is that I'm using JBoss 4.0.3SP1 and I have SLSB#1 in a cluster trying to connect to SLSB#2 in a different cluster. I can do it find using the regular JNDI, but as soon as I try to use the HA-JNDI it fails to do the lookup with a NameNotFoundException.
> jboss.xml for SLSB#2:
>
> <session>
> <ejb-name>MyStatless</ejb-name>
> <jndi-name>ejb/MyStatless</jndi-name>
> <clustered>true</clustered>
> </session>
> Global JNDI Namespace for SLSB#2
> +- ejb (class: org.jnp.interfaces.NamingContext)
> | +- MyStatless-RemoteInvoker (class: org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxyHA)
> | +- MyStatless-HomeInvoker (class: org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxyHA)
> | +- MyStatless (proxy: $Proxy64 implements interface it.csi.oss.clusterejb.interfaces.MyStatlessHome,interface javax.ejb.Handle)
> Code snipit for SLSB#1 :
> InitialContext ic1;
> MyStatlessHome home=null;
> try {
> ic1 = new InitialContext();
> String contextFactory = (String) ic1.lookup("java:comp/env/contextFactory");
> String urlMyStatless = (String) ic1.lookup("java:comp/env/urlMyStatless");
> String jndiMyStatless = (String) ic1.lookup("java:comp/env/jndiMyStatless");
> Properties env =new Properties();
> env.setProperty(Context.INITIAL_CONTEXT_FACTORY,contextFactory);
> env.setProperty(Context.PROVIDER_URL,urlMyStatless);
> System.out.println("+++++++ @ Sono MyStalessClient Iniziato lookup : contextFacry ="+ env.getProperty(Context.INITIAL_CONTEXT_FACTORY)+" url = "+ env.getProperty(Context.PROVIDER_URL) );
> InitialContext ic = new InitialContext(env);
> Object objRef = ic.lookup(jndiMyStatless);
> home = (MyStatlessHome)PortableRemoteObject.narrow(
> objRef, MyStatlessHome.class);
> } catch (NamingException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> ejb-jar.xml for SLSB#1 :
> <session >
> <description><Description for MyStatlessClient]]></description>
> <display-name>Name for MyStatlessClient</display-name>
> <ejb-name>MyStatlessClient</ejb-name>
> <home>it.csi.oss.clusterejb.interfaces.MyStatlessClientHome</home>
> <remote>it.csi.oss.clusterejb.interfaces.MyStatlessClient</remote>
> <ejb-class>it.csi.oss.clusterejb.ejb.MyStatlessClientSession</ejb-class>
> <session-type>Stateless</session-type>
> <transaction-type>Container</transaction-type>
> <env-entry>
> <env-entry-name>contextFactory</env-entry-name>
> <env-entry-type>java.lang.String</env-entry-type>
> <env-entry-value><![CDATA[org.jnp.interfaces.NamingContextFactory]]></env-entry-value>
> </env-entry>
> <env-entry>
> <env-entry-name>urlMyStatless</env-entry-name>
> <env-entry-type>java.lang.String</env-entry-type>
> <env-entry-value><![CDATA[jnp://cst003.csi.it:1200]]></env-entry-value>
> </env-entry>
> <env-entry>
> <env-entry-name>jndiMyStatless</env-entry-name>
> <env-entry-type>java.lang.String</env-entry-type>
> <env-entry-value><![CDATA[ejb/MyStatless]]></env-entry-value>
> </env-entry>
> </session>
> StackTrace on context.lookup() :
> 2006-05-04 12:48:35,746 INFO [STDOUT] javax.naming.NameNotFoundException: ejb/MyStatless
> 2006-05-04 12:48:35,746 INFO [STDOUT] at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:223)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:134)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:324)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:229)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at $Proxy84.lookup(Unknown Source)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:610)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 2006-05-04 12:48:35,747 INFO [STDOUT] at javax.naming.InitialContext.lookup(InitialContext.java:347)
> ..
> ..
> ..
> -Thanks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-973) Cache Invalidation fails when redeploy CMP beans
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-973?page=all ]
Brian Stansberry updated JBAS-973:
----------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> Cache Invalidation fails when redeploy CMP beans
> ------------------------------------------------
>
> Key: JBAS-973
> URL: http://jira.jboss.com/jira/browse/JBAS-973
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, EJB2
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: coneheed .
> Java version: 1.4.2_04,Sun Microsystems Inc.
> Java VM: Java HotSpot(TM) Client VM 1.4.2_04-b05
> ,Sun Microsystems Inc.
> OS-System: Windows 2000 5.0,x86
> We have in place a clustering architecture as described
> in the JBoss clustering book.
> It currently consists of 3 nodes. 2 "read-only" nodes
> whose CMP entity beans have read-only accessor
> methods and a "read-write" node where the entity beans
> have "read-write" accessor methods.
> We use the cache invalidation architecture (based on
> JGroups) to link the read-only and read-write beans
> together. Changes to the RW beans cause invalidation in
> the RO beans and the data remains consistent.
> This all appears to work fine until we redeploy our
> application jar files. The system continues to function
> but we get out of date data in our RO beans. Basically
> the RO beans are not asked to ejbLoad and hence re-
> read the data from the DB.
> Bounce all 3 nodes and the system works fine again.
> Redeplying to the RW node is OK but redeploying to the
> RO node breaks the cache invalidation.
> Forum article:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=50823
> Regards
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-3096) Add a maxInactiveInterval concept to ClusteredSingleSignOn
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3096?page=all ]
Brian Stansberry updated JBAS-3096:
-----------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> Add a maxInactiveInterval concept to ClusteredSingleSignOn
> ----------------------------------------------------------
>
> Key: JBAS-3096
> URL: http://jira.jboss.com/jira/browse/JBAS-3096
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service, Security, Clustering
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.0.6.CR1
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> SSOs are currently invalidated when all sessions associated with the SSO are expired. The problem is webapp undeploy or server shutdown can result in all sessions being expired, even though the sessions are distributed and can thus be accessed on other cluster nodes. If the user then fails over to another server, the SSO is gone.
> Not invalidating SSOs when all sessions expire can lead to memory leaks -- SSOs that never can removed from the local and distributed caches.
> Idea here is to timestamp the sso when all its sessions are expired, and then some configurable time later invalidate the sso if no new sessions have been added.
> Issues:
> 1) The TC background thread doesn't call into Valves, so there is no natural thread to check for "expired" SSOs. I'm considering hijacking the regular TC bg thread, since it ends up calling into the valve whenever it expires a session. That's ugly though.
> 2) Have to make sure that the other cluster nodes know the sso is "semi-expired" so they can do the expiration check, since often the node where the sso originally lived has been shut down. This should be simple; just another TreeCache event to monitor.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Commented: (JBREM-27) Support for HTTP/HTTPS proxy
by susanin (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-27?page=comments#action_12340008 ]
susanin commented on JBREM-27:
------------------------------
Hi Tom,
we have a setup, where a remoting client tries to access some EJB3 beans deployed JBoss. Since client is behind a firewall, we decided to use RMI-over-HTTP to access the server and we do it via an http proxy. So, we set system
properties http.proxyHost and httpProxy.port like follows:
http.proxyHost =www-proxy.domain.com
http.proxyPort = 8080
and the real http address we want to access is:
http://x.y.z.w:8888/SharedStateManager (real IP address is now shown here)
We have discovered that proxy support works incorrectly in current implementation of remoting. Under ethereal, we have observed the following:
POST http://www-proxy.domain.com:8080http://x.y.z.w:8888/SharedStateManager HTTP/1.1
Content-Type: application/octet-stream
User-Agent: Java/1.5.0
Host: www-proxy.domain.com:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Proxy-Connection: keep-alive
Content-Length: 1169
The problem is the first line. It is totally wrong. This is not the format expected by HTTP proxies.
And this line is create by the new URL(...) call in the class HTTPClientInvoker arount his code:
// now determin if going to use proxy or not
if (proxyHost != null && proxyOn)
{
// is ok if port is -1 since URL constructor will use default port for protocol
externalURL = new URL("http", proxyHost, proxyPort, url); // <---------------- This is WRONG!!!
httpURLConn = (HttpURLConnection) externalURL.openConnection();
// since know it is a proxy being used, see if have proxy auth
String proxyAuth = getProxyAuth(metadata);
if (proxyAuth != null)
{
httpURLConn.setRequestProperty("Proxy-Authorization", proxyAuth);
}
}
The bug is still present in the latest CVS version:
http://fisheye.jboss.org/viewrep/JBoss/JBossRemoting/src/main/org/jboss/r...
I don't know exactly, how to fix it, but may be something like following idea can help?
1) Remember current global proxy related properties
2) Change global proxy related properties (e.g. http.proxyHost, etc) to the required values
3) Let the HttpURLConnection create a connection/url using this properties
4) Restore global properties afterwards.
Hope, you will fix this bug easily and pretty soon.
Best Regards,
Ivan
> Support for HTTP/HTTPS proxy
> ----------------------------
>
> Key: JBREM-27
> URL: http://jira.jboss.com/jira/browse/JBREM-27
> Project: JBoss Remoting
> Issue Type: Feature Request
> Components: transport
> Reporter: Thomas Diesler
> Assigned To: Tom Elrod
> Priority: Optional
> Fix For: 1.2.0 final
>
>
> This request showed up on the web services forum. Proxies are currently suported in axis-ws4ee.jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Commented: (JBAS-3227) JNDIView.getHAJndiAttributes NPE
by Heiko W. Rupp (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3227?page=comments#action_12340005 ]
Heiko W. Rupp commented on JBAS-3227:
-------------------------------------
I have fixed this in JBAS-3260 as I forgot to look for a jira issue before reportig myself :-/
> JNDIView.getHAJndiAttributes NPE
> --------------------------------
>
> Key: JBAS-3227
> URL: http://jira.jboss.com/jira/browse/JBAS-3227
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Scott M Stark
> Assigned To: Scott M Stark
> Fix For: JBossAS-4.0.5.CR1
>
>
> Invoking the JNDIView.list operation is producing an NPE if the HAJNDI service is not deployed:
> 20:49:18,140 ERROR [JNDIView] JNDIView.getHAJndiAttributes() failed
> java.lang.NullPointerException: name cannot be null
> at javax.management.ObjectName.construct(ObjectName.java:342)
> at javax.management.ObjectName.<init>(ObjectName.java:1304)
> at org.jboss.naming.JNDIView.getHAJndiAttributes(JNDIView.java:836)
> at org.jboss.naming.JNDIView.getHAUrl(JNDIView.java:811)
> at org.jboss.naming.JNDIView.list(JNDIView.java:193)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
> at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months