January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1858) User registration portlet should be configurable to disable new registrations

by dpocock (JIRA)

User registration portlet should be configurable to disable new registrations ----------------------------------------------------------------------------- Key: JBPORTAL-1858 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1858 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.3 Final Environment: Debian, JBoss 4.2.1.GA Reporter: dpocock There should be a configuration option for the User Portlet allowing the administrator to choose whether new user registrations are permitted. This option should be disabled by default - in other words, new registrations should not be possible until the administrator has enabled this option. A more elaborate solution might involve a combination of the following features: - require the administrator to approve each new registration - only allow registration from trusted IP addresses - the user must validate their email address - the email address must match a regular expression or be on a pre-defined list -- 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

16 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-752) SSLSocket runs into BindException

by Claudia Richter (JIRA)

SSLSocket runs into BindException --------------------------------- Key: JBREM-752 URL: http://jira.jboss.com/jira/browse/JBREM-752 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.0.SP4, 2.2.0.SP3, 2.2.0.SP2, 2.2.0.SP1, 2.2.0.GA (Bluto), 2.2.0.Beta1 (Bluto) Reporter: Claudia Richter during a Socket refresh in the SocketServerInvoker Class (Method refreshServerSocket() ) sometimes a BindException occures. The reason is that reuseAddress is set after the ServerSocket is bound. It is necessary to first create an unbound ServerSocket, then set reuseAddress and then bind the ServerSocket. -- 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

16 years, 4 months

3
5
0 / 0

[JBoss JIRA] Created: (JBREM-846) Fix race in JNIDDetector

by Ron Sigal (JIRA)

Fix race in JNIDDetector ------------------------ Key: JBREM-846 URL: http://jira.jboss.com/jira/browse/JBREM-846 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) When the org.jboss.remoting.detection.jndi.JNDIDetector heartbeat thread does a clean detect and discovers that a server is unreachable, it calls checkInvokerServer(), which, among other things, tells its org.jboss.remoting.network.NetworkRegistry to inform listeners of the loss of a server. It then calls org.jboss.remoting.detection.AbstractDetector.detect(), passing the org.jboss.remoting.detection.Detection representing the server that is no longer available. However, detect() treats the Detection as a *new* server, and it tells its org.jboss.remoting.network.NetworkRegistry to inform listeners of a new server. This problem was turned up by the occasional failure of org.jboss.test.remoting.detection.jndi.RestartTestCase. The test fails inconsistently because NetworkRegistry sends its notifications in separate threads, and RestartTestCase is expecting to hear that (1) the old server has died, and (2) a new server has replaced it. If the notifications are received in order, than the test passes, and if they are received out of order it fails. The solution is simply to not call AbstractInvoker.detect() when a server has died. -- 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

16 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1856) Weather portlet doesn't recognise other units

by dpocock (JIRA)

Weather portlet doesn't recognise other units --------------------------------------------- Key: JBPORTAL-1856 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1856 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.3 Final Environment: Debian, JBoss 4.2.1.GA Reporter: dpocock Change the portlet instance preferences to use the URL for Paris, with Centigrade instead of Farenheit: http://xml.weather.yahoo.com/forecastrss?p=FRXX0076&u=c The portlet displays the temperate values in centigrade, but with the symbol `F'. E.g., if the temperature is 5 degrees C, the portlet says 5F. Looking at the RSS feed in the browser, it appears that it supplies the correct units: <yweather:location city="Paris" region="" country="FR"/> <yweather:units temperature="C" distance="km" pressure="mb" speed="kph"/> <yweather:wind chill="-5" direction="70" speed="11.27" /> <yweather:atmosphere humidity="76" visibility="9.99" pressure="0" rising="0" /> <yweather:astronomy sunrise="8:44 am" sunset="5:04 pm"/> -- 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

16 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-745) client unable to send if server recycles

by John Mazzitelli (JIRA)

client unable to send if server recycles ---------------------------------------- Key: JBREM-745 URL: http://jira.jboss.com/jira/browse/JBREM-745 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP4 Reporter: John Mazzitelli Assigned To: Ron Sigal I have TestNG unit test that fails about 75% of the time. See attached. The issue here is that if a server shuts down and then restarts, the client will fail to be able to send a message to it. Replication works like this: 1. create and start a connector 2. create and connect a client 3. send a message to the server and see that it works (which creates a ServerThread worker thread on server side) 4. stop connector and the re-start it 5. send a message to the server and see that it FAILS due to: org.jboss.remoting.ServerInvoker$InvalidStateException: Can not process invocation request since is not in started state. at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:745) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163) at org.jboss.remoting.Client.invoke(Client.java:1550) at org.jboss.remoting.Client.invoke(Client.java:530) at org.jboss.remoting.Client.invoke(Client.java:518) -- 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

16 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-706) In socket transport, prevent client side oneway invocations from artificially reducing concurrency

by Ron Sigal (JIRA)

In socket transport, prevent client side oneway invocations from artificially reducing concurrency -------------------------------------------------------------------------------------------------- Key: JBREM-706 URL: http://jira.jboss.com/jira/browse/JBREM-706 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta2 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta2 (Bluto) There is a subtle problem with the handling of client side oneway invocations in the socket transports (and descendants). After the invocation has been marshalled to the wire, the connection is returned to the connection pool, from which it can be reused, even if the server side handler is still processing the previous invocation. Consequently, invocations can back up and run serially instead of running concurrently. The following dialogue exposes the problem and possible solutions: =============================================================================================================== Ron Sigal wrote Hi Tom, I just noticed an interesting phenomenon that I wanted to tell you about. Maybe it'll be obvious to you, but it surprised me. I'm writing unit tests for socket and http, since they behave differently on oneway invocations. I've got a oneway ThreadPool with two threads and I make 4 oneway invocations, one right after the other. The handler waits for 5 seconds before returning. I expected that they would all run on the server simultaneously, but they don't. What happens is something like this: (1) invocation 1 gets made on thread 1 and socket connection 1 to ServerThread 1 is created; (2) invocation 2 gets made on thread 2 and socket connection 2 to ServerThread 2 gets created; (3) invocation 3 gets made on thead 1 and socket connection 1 gets reused. But ServerThread 1 is still sleeping, so invocation 3 waits for 5 seconds. Not a big deal, but I might not have guessed it if I hadn't seen it. =============================================================================================================== Ron Sigal wrote Hi Tom, Well, it's stranger than I thought. It turns out that for client side oneway invocations, socket, which returns immediately after marshaling the invocation, can be slower than http, which waits for a response. Consider a client side oneway threadpool with 2 threads and a queue of size 1, and suppose there are 4 invocations in quick succession. The handler takes 5 seconds per invocation. http: 1. 1st invocation runs in the first threadpool thread. 2. 2nd invocation runs in the second threadpool thread 3. 3rd invocation goes on the queue 4 4th invocation runs on the main thread Assuming there are at least 3 server threads, invocations 1, 2, and 4 run in the first 5 seconds, and then invocation 3 runs. Total time 10 seconds. socket (one possible scenario): 1. 1st invocation runs in the first threadpool thread and returns the socket connection to the pool 2. 2nd invocation runs in a threadpool thread, finds the pooled connection, marshals the invocation, and returns the connection to the pool. On the server side, the ServerThread runs the invocations after finishing the 1st invocation. 3. 3rd invocation runs in a threadpool thread, finds the pooled connection, marshals the invocation, and returns the connection to the pool. On the server side, the ServerThread runs the invocations after finishing the 2nd invocation. 4. 4th invocation runs in a threadpool thread, finds the pooled connection, marshals the invocation, and returns the connection to the pool. On the server side, the ServerThread runs the invocations after finishing the 3rd invocation. Total time: 20 seconds. I've seen this happen. The scary thing is that the story scales. With more threads on the client side and server side, http can run more and more invocations in parallel. Whereas socket could end up running arbitrarily many invocations serially. I think that having MicroSocketClientInvoker return after marshaling a client side oneway invocation isn't a good idea. Ovidiu's JBREM-685 ( <http://jira.jboss.com/jira/browse/JBREM-685>A server needs redundant information to detect a one way invocation) <http://jira.jboss.com/jira/browse/JBREM-685> gives me a half baked idea. Maybe these two ways of tagging a oneway invocation could be used to distinguish client side from server side oneway invocations. Or something like that. By the way, I think that there's no problem with server side oneway invocations, since a single ServerInvoker can keep shoving invocations into the threadpool. -Ron =============================================================================================================== Tom Elrod wrote: Wow. Never thought about this happening but makes sense. So the real problem with the socket client invoker is it pools the connections when doing oneway invocations. So it is queuing up invocations on the same connection which can only be processed serially on the server side. Think maybe your idea about using the ONEWAY_FLAG on the client can work. Basically am thinking we'd have to check that before returning the connection to pool and if is set, then throw away the connection (i.e. don't put back in pool). This way, the next oneway invocation would not be using the same connection and on the server side, should use another available server thread to do the process (so could be in parallel). However, this means that incur more overhead on the client side to create a new connection for each oneway invocation, but is maybe worth the cost (too bad we can't tell if serve will take a long time or not). Let me know what you think. =============================================================================================================== Ron Sigal wrote: It seems to me that MicroSocketClientInvoker could: ... 2. in the case of client side oneway invocations, either throw away the connection and return immediately, or just not return until it gets a response from the server. Since it's on a separate thread, maybe the latter is preferable, since then it can return the connection to the pool after it gets a response. =============================================================================================================== Tom Elrod wrote: Yeah, this is a tricky one. On the one hand, if don't throw away the connection and wait for the server response AND the server takes a long time, would be possible to exhaust the pool since all threads will be stuck waiting for server to respond. With the new change to the thread pool to use the RUN mode, would mean calling threads would then be making the remote call and would pretty much be negating the purpose of oneway client side (since client caller thread would be making the network call and blocking until gets response). However, if do throw away the connection, then means that in general have defeated purpose of connection pooling since will have to create a new connection each time oneway client side invocations are made. So if the server processes the requests quickly, would be taking on the extra overhead of creating a new client connection for every call. Hmmm. Could go either way if feel strongly one way or another. However think I am leaning towards throwing away the connection. =============================================================================================================== Ron Sigal wrote: This might be complicating things, but for client side oneway invocations we could set a short per invocation timeout, say 1 second or 5 seconds. If the response comes back, put the connection back in the pool. If it times out, throw the connection away. Don't know how to pick the timeout, though. =============================================================================================================== Tom Elrod wrote: I hate getting too complicated as tends to increase the chance of introducing bugs. However, if wanted to do this, would say need to make the timeout very low, i.e. 1 second. -- 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

16 years, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1238) Node should not enter STARTED state until it has applied state from buddies.

by Manik Surtani (JIRA)

Node should not enter STARTED state until it has applied state from buddies. ---------------------------------------------------------------------------- Key: JBCACHE-1238 URL: http://jira.jboss.com/jira/browse/JBCACHE-1238 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Replication Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA -- 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

16 years, 4 months

1
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1857) RSS portlets (News, Weather) must allow proxy and HTTP authentication settings to be configured at runtime

by dpocock (JIRA)

RSS portlets (News, Weather) must allow proxy and HTTP authentication settings to be configured at runtime ---------------------------------------------------------------------------------------------------------- Key: JBPORTAL-1857 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1857 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.6.3 Final Environment: Debian, JBoss 4.2.1.GA Reporter: dpocock The following parameters need to be configurable for the news and weather portlets: - HTTP username for the RSS server - HTTP password for the RSS server - HTTP proxy hostname - HTTP proxy port number - HTTP proxy username - HTTP proxy password It should be possible to define these settings differently for every portlet instance in the portal. A workaround exists for using a proxy, but it causes the same proxy settings to be used for all portlets. The workaround: add the following to the JAVA_OPTS in $JBOSS_HOME/bin/run.conf: -Dhttp.proxyHost=192.168.1.1 -Dhttp.proxyPort=3128 -Dhttp.nonProxyHosts=192.168.1|localhost There are more proxy options (HTTPS, FTP, etc) describe here: http://java.sun.com/j2se/1.5.0/docs/guide/net/proxies.html -- 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

16 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1237) Version info not available with java -jar

by Manik Surtani (JIRA)

Version info not available with java -jar ------------------------------------------ Key: JBCACHE-1237 URL: http://jira.jboss.com/jira/browse/JBCACHE-1237 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA Probably something to do with the way maven builds the 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1244) Buddy Manager to create _BUDDY_BACKUP_ region on initialisation before accepting any state or membership requests from buddies

by Manik Surtani (JIRA)

Buddy Manager to create _BUDDY_BACKUP_ region on initialisation before accepting any state or membership requests from buddies ------------------------------------------------------------------------------------------------------------------------------ Key: JBCACHE-1244 URL: http://jira.jboss.com/jira/browse/JBCACHE-1244 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Buddy Replication Affects Versions: 2.1.0.CR2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA Prevents a race condition in creating the node on the fly, causing potential timeout exceptions. -- 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

16 years, 4 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008