search

jakartaee / messaging

Jakarta Messaging
https://eclipse.org/ee4j/messaging
Other
39 stars 33 forks source link

Vendor-defined acknowledgement modes #169

Open glassfishrobot opened 9 years ago

glassfishrobot commented 9 years ago

Several vendors currently support non-standard acknowledgement modes as vendor-specific extensions.

(Edited) The most common vendor-specific modes are no-acknowledgement mode (see #168 and #21) and individual-acknowledge mode (see #95), and these are already proposed for standardization.

However individual vendors may wish to offer additional acknowledgement modes which are probably too vendor-specific to be suitable for incorporating in the standard.

Currently the JMS specification does not allow createSession and createContext to support modes other than the four defined in the specification. It is proposed to relax this restriction to allow vendors to define additional modes, so long as their integer value is within a special defined range.

Applications which use such vendor-specific modes will, inevitably, not be portable.

The specification for Session#getAcknowledgementMode and JMSContext#getSessionMode would need to be extended to cover this new feature.

One drawback of defining an integer range for vendor-specific modes is the possibility that two vendors may choose the same value. One way to avoid this would be to define new createContext and createSession methods which allow the session/acknowledgement mode to be specified as a string. JMS-defined modes would start with javax.jms, vendor-defined modes would start with a vendor-specific string such as com.vendorname.

Affected Versions

[2.0]

glassfishrobot commented 6 years ago
glassfishrobot commented 9 years ago

@glassfishrobot Commented Reported by @nigeldeakin

glassfishrobot commented 9 years ago

@glassfishrobot Commented chris.barrow said: An integer range for vendors combined with a registry to avoid collisions might be a good way to go. It would avoid increasing the complexity of the API and also be a useful source of possible modes we might want to add to the standard going forward.

glassfishrobot commented 9 years ago

@glassfishrobot Commented clebertsuconic said: wouldn't be better to add two pre-defined integers such as NO_ACK and individual_ack and let it be optionally implemented?

glassfishrobot commented 9 years ago

@glassfishrobot Commented chris.barrow said: That's a possibility, but if we do that we should provide a means of knowing if they are supported.

glassfishrobot commented 9 years ago

@glassfishrobot Commented @nigeldeakin said: This proposal is intended to cater for "additional acknowledgement modes which are probably too vendor-specific to be suitable for incorporating in the standard.". A search through vendor documentation suggests that a number of other modes are in use.

One of the reasons for proposing this is to provide a way for vendors to support such modes whilst still conforming to the JMS specification.

I'm not enthusiastic about adding more createSession and createContext methods, but this would offer a self-managing mechanism for avoiding collisions between vendors. Managing a registry of vendor-defined integer acknowledgement modes sounds like an administrative burden for someone. (Are there any precedents for it in JCP specifications?).

Of course we could decide that avoiding such collisions was not necessary, since each vendor would doubtlessly define their own static constants, and applications which used them would not compile if a different vendor was used.

glassfishrobot commented 9 years ago

@glassfishrobot Commented @nigeldeakin said: Comment received from Matthew White:

I like the idea of the No and message specific ack modes; we've had requests for customers for these. In our experience we've found that some developers don't realise that they have started to use vendor specific extensions. Or don't full realise the impact. Having potential overlapping integer values therefore I would be wary off. Strings possibly might be better here.

An alternative could be to have the extra no/message ack modes, but a vendor specific ackmode, and a separate way of passing the vendor specific info (setVendorInfo(...)) that way application writers are forced to know they have stepped outside the spec.

Indeed what over types of ack mode could be considered? May it be worth considering more of these for the spec.

glassfishrobot commented 9 years ago

@glassfishrobot Commented clebertsuconic said: We already use that integer for vendor specific modes right now even thought that is "not supported".

glassfishrobot commented 9 years ago

@glassfishrobot Commented chris.barrow said: Good point. Perhaps all we need to do is reserve a range of acknowledgeMode values for use by the JMS specification, like 1 to 20, i.e. require that vendor specific modes not use those values. This is a common future proofing technique used in many specs, for example RFC 6455 (WebSocket). Here some examples of values being used:

If we reserve 1 through 20 then only ActiveMQ of the above list would be impacted, and that would be mitigated if we implement JMS _SPEC-95 and make the new CLIENT_INDIVIDUAL_ACKNOWLEDGE mode have value 4 (which would be theexpected value to choose since JMS 1.1 and 2.0 only use values 1 through 3).

glassfishrobot commented 9 years ago

@glassfishrobot Commented @nigeldeakin said:

glassfishrobot commented 9 years ago

@glassfishrobot Commented @nigeldeakin said: The simplest approach would indeed to be to reserve a range (e.g. 0-20) for JMS-defined modes. We would also need to amend the spec to explicitly allow vendor-defined modes, so long as they are outside the reserved range.

(Edited) Note that we have separate proposals to standardize "no-ack" mode: (#168 and #21) and "individual-ack" mode (#95). When choosing values for those modes we would probably want to try to avoid values which we know are already in use, though we couldn't guarantee this. Even though the spec is entitled to choose any values it wants, we don't want to place obstacles in the way of vendors adopting JMS 2.1 if we can avoid them.

glassfishrobot commented 9 years ago

@glassfishrobot Commented Issue-Links: is related to JMS_SPEC-95 JMS_SPEC-168

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-169