[JBoss JIRA] Created: (JBJMX-104) SNMP Adaptor doen't accept TruthValue according to SNMP v2
by Luca Stancapiano (JIRA)
SNMP Adaptor doen't accept TruthValue according to SNMP v2
----------------------------------------------------------
Key: JBJMX-104
URL: http://jira.jboss.com/jira/browse/JBJMX-104
Project: JBoss JMX
Issue Type: Patch
Environment: linux , eclipse, I'm using jboss 4.0.4-GA
Reporter: Luca Stancapiano
hi.......if you try to take a TruthValue using a MIB Browser , you receive nothing because org.jboss.jmx.adaptor.snmp.agent.RequestHandlerImpl doesn't manage booleans ....I added a patch into getValueFor method ( row 474 ) that manage it with good results. I think that setValue method doesn't need the same correction because joesnmp can simply to interpret TruthValue as SnmpStringOctet object
row 474:
else if (val instanceof Boolean)
{
Boolean in = (Boolean) val;
ssy = new SnmpOctetString(in.toString().getBytes());
}
--
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, 3 months
[JBoss JIRA] Created: (JBRULES-460) Please allow ftp downloads to "resume"
by hoogenbj (JIRA)
Please allow ftp downloads to "resume"
--------------------------------------
Key: JBRULES-460
URL: http://jira.jboss.com/jira/browse/JBRULES-460
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Environment: Any
Reporter: hoogenbj
Assigned To: Mark Proctor
Priority: Minor
Hi Guys
In my part of the world (South Africa) we still get dropped connections and here a 128kbps connection counts as broadband. It is extremely &*^&^$%#$ annoying if I lose a connection while trying to download a 23MB file (JBoss Rules 3.0.4 binary with deps) and I have to start from the beginning because your ftp server does not allow "resume". (I've already made 3 attempts today)
PLEASE PLEASE PLEASE change it. Other parts of JBoss do allow it so why not you?
I'm not sure why you disallow it. Maybe you think that people multiplexing a download over multiple connections (with DAP) put too much load on the server?
Think about it: you are actually increasing the load by not allowing it, because someone like me have to make multiple attempts at downloading something before succeeding. If I have to try 3 times and come close to succeeding the first two times, it is effectively the same as three people downloading the same software. Allow resume and I'll succeed sooner and go away sooner.
Again, PUHHLEASSEEE!
Regards
Johan Hoogenboezem
--
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, 3 months
[JBoss JIRA] Created: (JBSER-84) Improve serialization of immutable objects
by Michael Santos (JIRA)
Improve serialization of immutable objects
------------------------------------------
Key: JBSER-84
URL: http://jira.jboss.com/jira/browse/JBSER-84
Project: JBoss Serialization
Issue Type: Feature Request
Reporter: Michael Santos
Assigned To: Clebert Suconic
It is common for objects to contain references to hundreds or thousands of equal immutable object instances, especially java.lang.Number subclasses. Some immutable objects produce a considerable serialized amount of information, such as java.math.BigDecimal. However, there's usually no reason for different instances being used to represent the same value; they only exist due to the way they were produced (parsing &, conversion APIs and JDBC are definitely fine examples of that). Experiments on a particular project have shown replacing all these equal instances by one of them can reduce the serialized size of some objects by half.
Therefore, JBoss Serialization should provide way to allow users to tell it's ok to use the same reference for all these immutable instances and which classes are to be considered immutable and replace them during the writing phase. This would be much more efficient and wouldn't require developers to rewrite their code in order to optimize serialization of some objects. A global way, such as system property, of telling the API to do this by default with the most commonly used Java SE classes would be desirable as well.
--
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, 3 months
[JBoss JIRA] Created: (JBAS-3724) NotFoundInDispatcherException from InvokerLocator when accessing remote calls when on a non default port
by Grant Quimby (JIRA)
NotFoundInDispatcherException from InvokerLocator when accessing remote calls when on a non default port
--------------------------------------------------------------------------------------------------------
Key: JBAS-3724
URL: http://jira.jboss.com/jira/browse/JBAS-3724
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services, EJB3, Remoting
Affects Versions: JBossAS-4.0.4.GA
Environment: One JBoss 4.0.4.GA install with two instances, one on the default ports and one on ports with an increase of 1000 on all port numbers.
Reporter: Grant Quimby
Assigned To: Dimitris Andreadis
Priority: Blocker
When trying to access a remote application that is running in a server instance that does not have the default InvokerLocator port (3873) the remote caller recieves a NotFoundInDispatcherException when trying to call a method in the EJB3 Stateless Session Bean as the EJB3 Session Bean's InvokerLocator is at port 4873 and not port 3873 where the Remote Proxy looks.
Similar issue for Service Beans at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89537
This is okay presently but in approximately two weeks we need to be running four instances with Session beans in two of them, which is currently not possible in a production version.
--
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, 3 months