January 2009 - jboss-user - Jboss List Archives

by mohitanchlia

Thanks. So new release of Jboss remoting doesn't do retries? Is it then just 1 try then? Does the new document reflect all the new features. It looked pretty much the same. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199387#4199387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199387

17 years, 3 months

1
0
0 / 0

[Remoting] - Re: JBoss Remoting and compression

by ron.sigal＠jboss.com

Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199386#4199386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199386

17 years, 3 months

1
0
0 / 0

[Remoting] - Re: Socket Invoker timeout

by ron.sigal＠jboss.com

"mohitanchlia" wrote : | Reason I have been asking same question is because below timeout corresponds to the timeout I have set in timeout attribute. | My mistake, again. org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket() overrides MicroSocketClientInvoker.createSocket(), and the former uses the configured timeout for the Socket.connect() call. You're right! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199385#4199385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199385

17 years, 3 months

1
0
0 / 0

[Remoting] - Re: JBoss Remoting and compression

by doychin

You can find the source code of compression invoker marshaller/unmarshaller as attachments in the JIRA report. Doychin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199384#4199384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199384

17 years, 3 months

1
0
0 / 0

[Remoting] - Re: Why so many retries?

by ron.sigal＠jboss.com

anonymous wrote : | anonymous wrote : | | I don't follow. What's the outcome? | | | | It worked just fine. It reduced the number of times it was trying to get the Socket (client invoker) to the server. | Great! "mohitanchlia" wrote : | I have another question though, In clustered environment when is the pool created on client side? Because until client gets first request it will not know which servers to connect to. Is it that after first client invocation "CLIENT" retains the connection? | Exactly. Each time the EJB3 proxy is called to make an invocation, it will create an org.jboss.remoting.Client. The Client will look for an org.jboss.remoting.transport.socket.MicroSocketClientInvoker for the currently designated server, and either (1) reuse an existing MicroSocketClientInvoker, if there is one, or (2) create a new MicroSocketClientInvoker. It is the MicroSocketClientInvoker that stores the connection pool. "mohitanchlia" wrote : | When I read the documentation of new Jboss remoting it still has numberOfRetries. I am still confused about how retries work because what you described differs from what's mentioned in the doc. Or may be the way I am interpreting is not right. My understanding is that server registry creates ClientInvoker (MicroSocket) and returns. Now when ClientInvoker tries to establish remote connection and at that time it tries for numberOfRetries until it gets successful connection. | Your misunderstanding is completely my fault, and I apologize. I failed to remove the reference to "numberOfRetries" from the Remoting Guide. I have created JIRA issue "Remove reference to "numberOfRetries" parameter from Remoting Guide" (https://jira.jboss.org/jira/browse/JBREM-1078) to make sure I fix the Guide for the next release. You're right, by the way, about the sequence of events. Client.connect() just creates the MicroSocketClientInvoker. When Client.invoke() is called, the MicroSocketClientInvoker will try to reuse an existing connection, or, if none exists and the maximum number of connections are not already in existence, it will create a new connection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199383#4199383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199383

17 years, 3 months

1
0
0 / 0

[Remoting] - Re: Socket Invoker timeout

by mohitanchlia

Reason I have been asking same question is because below timeout corresponds to the timeout I have set in timeout attribute. If that timeout was for read operation then why would NoRouteToHostException return in the timeout that I have specified. As you mentioned NoRouteToHostException occurs during connect. Everytime NoRouteToHostException occurs it returns in the timeout I specify. So If I change my timeout to 4000 ms then I see that too. The java.net.NoRouteToHostException doesn't represent a timeout. The "creation attempt took 5001 ms" message is just extra information provided by the invoker. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199382#4199382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199382

17 years, 3 months

1
0
0 / 0

[Remoting] - Re: Socket Invoker timeout

by ron.sigal＠jboss.com

"mohitanchlia" wrote : | | anonymous wrote : | | The java.net.NoRouteToHostException doesn't represent a timeout. The "creation attempt took 5001 ms" message is just extra information provided by the invoker. | | | | So does it really mean that timeout is on initial Socket connection creation and not on the read operation? | Well, 1. The timeout is configured for the read() operation, not the connect() operation. 2. The java.net.NoRouteToHostException is being thrown from the connect() operation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199380#4199380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199380

17 years, 3 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: Cache service not registered on cold start EAR persisten

by jaikiran

Looks like a deployment ordering issue. I can think of two options: 1) Create a folder named "deploy.last" in server/default/deploy folder and place your EAR file in that deploy.last folder. That way, your EAR will be deployed after everything else is deployed OR 2) Create a jboss-app.xml (if you dont already have one) and place it in the META-INF of your EAR. The jboss-app.xml can contain the following: <jboss-app> | <module> | <service>cache-config-service.xml</service> | </module> | </jboss-app> And package that cache-config-service.xml at the root of your EAR. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199379#4199379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199379

17 years, 3 months

1
0
0 / 0

[Remoting] - Re: JBoss Remoting and compression

by ron.sigal＠jboss.com

Hi Doychin, "doychin" wrote : | If you want I can provide you with full source code so you can use it to create the necessary updates in 2.x and 2.2 branches. | That would be great. Could you attach the source files to the JIRA issue at https://jira.jboss.org/jira/browse/JBREM-1077? Thanks, Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199378#4199378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199378

17 years, 3 months

1
0
0 / 0

[Remoting] - Re: Using remoting for RMI for EJB 2 with scoket connector a

by ron.sigal＠jboss.com

Glad to hear it. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199377#4199377 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199377

17 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-user January 2009