[JBoss JIRA] Created: (JBREM-864) CLONE -ServerInvoker#getMBeanObjectName() returns invalid ObjectName if host value is IPv6
by Ron Sigal (JIRA)
CLONE -ServerInvoker#getMBeanObjectName() returns invalid ObjectName if host value is IPv6
------------------------------------------------------------------------------------------
Key: JBREM-864
URL: http://jira.jboss.com/jira/browse/JBREM-864
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01, 2.2.2.SP2
Reporter: Takayoshi Kimura
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP3
IPv6 address contains ":" character, so it cannot be used in ObjectName.
2007-10-18 15:37:40,476 WARN [org.jboss.remoting.transport.Connector] Error registering invoker SocketServerInvoker[UNINITIALIZED] with MBeanServer.
javax.management.MalformedObjectNameException: Invalid character ':' in value part of property
at javax.management.ObjectName.construct(ObjectName.java:529)
at javax.management.ObjectName.<init>(ObjectName.java:1304)
at org.jboss.remoting.transport.Connector.init(Connector.java:402)
at org.jboss.remoting.transport.Connector.create(Connector.java:760)
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.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
at $Proxy0.create(Unknown Source)
at org.jboss.system.ServiceController.create(ServiceController.java:330)
at org.jboss.system.ServiceController.create(ServiceController.java:273)
at org.jboss.system.ServiceController.create(ServiceController.java:349)
at org.jboss.system.ServiceController.create(ServiceController.java:273)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
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.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.create(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:258)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
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
16 years, 10 months
[JBoss JIRA] Created: (JBREM-877) New Socket Connection is being Created for Every Client Request to the Server
by Kumarselvan Somasundaram (JIRA)
New Socket Connection is being Created for Every Client Request to the Server
-----------------------------------------------------------------------------
Key: JBREM-877
URL: http://jira.jboss.com/jira/browse/JBREM-877
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.2.2.SP2
Environment: Linux os , Pentium duo Processor with 3.6 Ghz clock Speed, 4GB Ram in this Postgresql Database also Running
Reporter: Kumarselvan Somasundaram
Priority: Critical
whenever EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,
The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0
new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization.
--
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, 10 months
[JBoss JIRA] Created: (JBAS-4389) nestedjarXXXX.temp files remain in the User's Temp directory on Windows after AS shutdown.
by Mark Spritzler (JIRA)
nestedjarXXXX.temp files remain in the User's Temp directory on Windows after AS shutdown.
------------------------------------------------------------------------------------------
Key: JBAS-4389
URL: http://jira.jboss.com/jira/browse/JBAS-4389
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.Beta2
Reporter: Mark Spritzler
When you startup the App Server some temp jar files are created in "C:\Documents and Settings\Username\Local Settings\Temp" directory. After you shutdown the App Server, a lot of them are deleted, but not all of them. After restarting the server many times those files that remain are all still there, causing your hard drive to run out of space. I had had 15 gigs used up by these remaining files.
Here are the statistics of restarting the server about 4 times after cleaning everything out of the Temp folder before the first startup.
Start
386 Files
73.5 MB
Shutdown
224 Files
33.7 Megabytes
Second start
546 Files
97.6 MB
Second Shutdown
576 Files
86.9 MB
Third start
// This tells me I didn't refresh(F5) Windows Explorer to get all the new files.
576 Files
86.9 MB
Third Shutdown
1024 Files
154 MB
Fourth start
1410 Files
228 MB
Fourth Shutdown
1280 Files
193 MB
Format of files remaining in temp
nestedjarNNNN.temp
--
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, 10 months